Slashdot Mirror
Ask Slashdot: Do Coding Standards Make a Difference?
An anonymous reader writes "Every shop I've ever worked in has had a 'Coding Style' document that dictates things like camelCase vs underscored_names, placement of curly braces, tabs vs spaces, etc. As a result, I've lost hundreds of hours in code reviews because some pedant was more interested in picking nits over whitespace than actually reviewing my algorithms. Are there any documents or studies that show a net productivity gain for having these sorts of standards? If not, why do we have them? We live in the future, why don't our tools enforce these standards automagically?"
...yes but not very much a all. Nothing beats clear thinking.
Need Mercedes parts ?
because when you leave\get fired\DIE, everyone can read your code and not have to interpret it, thus productivity gained.
I doubt there's any productivity gain by the people who write in a particular style but I think corporations want things done a specific way so other people can work on code someone else developed. When standards get too restrictive they can create problems. A few decades ago when I moved from Pascal to C I wrote a program to reformat my code into a standardized format...wasn't too difficult and it allowed me to focus on the algorithms, content, and GUI rather than the style of the code itself. Seems like it'd be a good thing for corporations to have...a tool that auto reformats into a standard corporation-approved format.
I find it impossible to believe that anyone has actually lost hundreds of hours in reviews due to style, unless they were purposely not following what are usually pretty simple guidelines.
The differences between one style and another are meaningless, but the value of having a consistent style across an entire codebase is, in my experience, enormous. If everyone can read your code as though it was their own, that does in fact save hundreds of hours of time across the team.
Listing the meaning of every acronym, no matter how well known, that's my favorite part of document reviews.
Coding standards save the hundreds of hours of somebody else going through your code and re-indenting it all so that you can't diff it any more.
Programmer doesn't like the coding standards that someone else set, decided to whine about it on slashdot.
Yes, having consistent code makes a difference, it lets you make more assumptions when reading code. If you can't manage to even manage to follow a simple style guide, you're probably doing all kinds of other sloppy things that are unwanted in the code.
Man up and spend a little while getting used to it, and using it properly.
The fact that you're even asking this question shows you've never had to deal with maintaining code which was written without regard for a consistent coding style. Deal with conforming to a coding style, and get back to us when you have a bit more experience in the real world.
I lost about three days of productivity on a new programming language (the Asterisk extensions.conf stuff, actually) because it turns out that that particular language treats whitespace after a comma in a function call as part of the passed parameter. A wonderful example of a language enforcing a language standard -- you cannot put a space after your commas, or the language will break. I only wish it had been documented a little bit better. On balance, though, I would argue that that's a perfect example of a very good reason NOT to strictly enforce coding style.
We live in the future, why don't our tools enforce these standards automagically?
Some do. As the developer it's your job to make sure it happens, however you do it.
As a result, I've lost hundreds of hours in code reviews because some pedant was more interested in picking nits over whitespace than actually reviewing my algorithms
Was the nit picker correct? That is, was he pointing out true variances from the standard? If so, the fastest way to appease him is to cram your ego and make the changes. If you're arguing about something that is clearly spelled out in the coding standard, then YOU are the one who is wasting time by arguing about it. If not, and the nit picker is just slinging shit, then call him out for wasting time in meetings.
Keeping a consistent style is important. If you are part of a larger project, then there needs to be a cross-project standard. I cannot say whaich practices/standards are best. You just need to have one.
Things like using solid variable/function names, providing sufficient (and quality) comments, and keeping similarity in architectural style matter. How many spaces you use (as long as you use some indentation) or what style of variable names you use makes no difference. And anyone who brings it up in a code review should be shouted down- the purpose of a code review is to find bugs, missed corner cases, unintended consequences of a change, and to find alternate ways to solve a problem. It is not there for cosmetic issues, and anyone who brings them up is wasting time for no gain and makes the code reviews of the entire organization less useful.
I still have more fans than freaks. WTF is wrong with you people?
We live in the future, why don't our tools enforce these standards automagically?
man gofmt
Of course it's a good idea. You wouldn't want to read a book printed wholly in italics, now would you? It's not that it's impossible to get used to it, only we got un-used to it and standards are useless unless you cling onto them at least for a while.
Ezekiel 23:20
If you can't code to published standards, what makes you think your algorithms are any better?
Consistent naming is important. It lets you quickly call into libraries that other people have written without having to double check, "was that camel cased or underscored spaced?"
But nit-picking over whitespace is simply annoying. Any person who insists on that much compliance might be trying to compensate for lack of performance in more important areas.
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
It's like reading slashdot. You come across someone who can barely spell, has trouble with homophones, puts extraneous apostrophes in, and it makes it much harder to read for someone who is used to reading. The same goes for coding. If the reviewer sees a bracket where he expects a curly brace, even though the two are interchangable, it's going to slow him down.
Plus, if you used three spaces instead of a tab, what other errors are in your code?
Free Martian Whores!
I ask because in the last 5 years I've been using various flavours of Eclipse and Visual Studio and both of them come with document formatting features that you can template.
The only thing I ask people if they plan on formatting a document during a change is to do it either before or after their change so I can review the differences more easily in source control revision history.
Oh and to answer the question, yes, I've found if the team can adhere to vaguely common style they can navigate their way through our entire codebase without getting lost in one individual's style preference.
Obviously YMMV in this regard.
crazy dynamite monkey
Ok you may spent an hour or more setting up the code beautifier with the rules but after that what does it take a min or so at most to be run?
It's a test on following orders and attention to detail. We don't need any of you rogue coders 'round here, see?
What political party do you join when you don't like Bible-thumpers *or* hippies?
I'll bet we could fairly easily construct a perl/awk/python script that will convert between the two, assuming one isn't already in standard use. Sounds like a waste of time to worry about it to me.
Coding standards makes quite a bit of difference. If I'm going to review the code you've supplied me with I'd better be able to clearly read and understand what you are doing. I'm a big believer / follower in the FIG PSR rules to follow.
With such poor standards as white space and curly braces, write a pretty routine to clean it up. One to convert to your standard and one to convert back to theirs.
I come for the world of 6 upper charter names names for fields/columns. There naming conventions mean something becuase every is abbrivated. We keep or stnadards on single sheet of paper to so that could be followed.
Now get of my lawn!
This seems to have given us the ability to benefit from a single coding standard for what's in our code base, while *not* spending any developer or manager time to have to worry about it getting/keeping it that way ...
happened to me. at a large networking company (I don't want to mention the name, for various reasons) I felt more comfortable with my own coding/indenting style, which included lots of whitespace (my eyes are old and the extra vertical WS helps isolate 'paragraphs' from each other and that clustering really helps me a lot).
my boss felt so strongly about it, though, that he'd constantly use that as a way of beating me up. eventually, I got fired and I think our conflict was a major part of that.
I have been coding for over 35 years (in C, mostly) and I have a damned good handle on how to code for readability and supportability. but when it comes to styles, the guy in charge wins, no matter what, even if there is no right answer, per se.
you should not code in a radically different way from the existing codebase, but to complain about line length (at the time, they were HARSH about keeping lines to 80chars max, which was so braindead) and my vertical whitespace just really ticked one or two people off enough that they complained and got me canned.
so, yes, those that want to pick fights, will do so over stupid little things and make a big damned deal about it, too. part of 'coding politics' I guess. large and small companies all have this problem and it won't ever go away.
better companies can be flexible. the more rigid ones, I find, have lost their way. writing code is not a mechanical thing; there's an art to it and to strip all individualism from the task is just plain wrong, to me.
--
"It is now safe to switch off your computer."
We have always had standardized checkstyle and jtidy rules as part of our build system. We have eclipse formatting configuration that everyone uses as well. Commits don't happen unless checkstyle is happy.
I thought everyone did this. I guess tooling is less developed in some languages, but it's not too hard to put this kind of thing into practice with a little bit of effort and buy-in.
Code Complete by Steve McConnell discusses this. It is not your code, it is the company's code, the team's code. Some poor bastard will need to read this code five years from now. All you need to do is to use for example astyle or uncrustify to automatically format all code, before it is even accepted for a code review. Correctly formatted code, by a computer, should be a prerequisite. If the code is not correctly formatted, call of the inspection/review and meet again at some other date.
Most IDEs have the ability to auto-format existing code. They also let you change the formatting rules if you prefer something different than the default. Your organization can just share formatting rules file. Code the way you want then hit the hot key before committing.
When you have many people working on the same code base coding standards are very important. Its impossible to keep every line of code fresh in your memory so when viewing your code or someone else's, quickly identifying what each part of the code does is very important. Knowing even something as simple as a standard variable naming convention used in a program can make the difference between jumping into a block of code and accurately modifying it or butchering it.
http://interserver.net/
Grammars and spelling came about in the 16th century or so, for much the same reason. Yud probbabli minde iff I rote anglich zis wai bekoz youd spend wai tu moch tim vonderrin wat I rote. If you think I'm exaggerating, try reading old English manuscripts -- or worse, old French manuscripts.
Embrace the coding standard, and enforce it for the next guy's sanity when it comes to maintenance. Ideally, setup pre-commit filters on your repo: if the code doesn't conform to the in-house standard, the repo should reject it; period, end of story. That way, nobody wastes time on it except those who aren't respecting them in the first place.
Another already suggested that nothing beats clear thinking. I agree, but don't dismiss how consistency in code formatting improves code readability and maintainability.
Conformity makes things easier to read; It depends on how extreme the grammer nazis go. The question is how much does it really matter that i used lowercase i's or incorrectly used a semicolon ... it depends on the context.
They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
I think it's not so much to encourage good practice and ensure standards, as it is to discourage bad practices that are very hard to standardize later. In fact, in newer versions of Visual Studio, when you rename a variable, it gives you the option to rename everywhere else the variable is referenced. That feature probably originated out of these standards. I don't care if you name your variable studentScore, studentscore, or StudentScore, but if you name it StudentS, ss, Sscore, please die, thanks.
It depends on what else is going to be put on the table.
A uniform, ubiquitous, documented coding standard can be of great help.
But it's still just a help or a tool, not a solution.
You still need to know how to effectively program, you have to get a fairly good knowledge about the underlying system, the environment and, of course, the problem the program is meant to solve.
I would say it's just like following a precise order in company bookkeeping.
It helps a lot, but you still need to follow the rules and the law.
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
That's why everyone has their own...
There are some standards / practices that are very important when it comes to making secure code. They avoid basic mistakes and so on. There should also be some minimal enforcement in terms of how to indent which always help to reread the code. Peer review for anything complex is also a good practice.
As for camel case, or hungarian notation, I feel that they are mainly a waste of time in the best of case. Being pedantic about code isn't going to help anyone or any project, in fact it might make a lot of talented people leave the company.
This guy thinks he's the shit programming wise and thus has to do his own thing. He's too good to be bound by the rules of everyone else. So he keeps fucking up and then crying about it.
His company should just can him.
Once I was put on a project with rather strict standards. I didn't like their naming conventions, and the style was noticeably different from mine. But I soon found that whichever of their programs I was assigned to, it was relatively easy to follow because of the similarity with the other programs in that system. In contrast, the system I'd been on before had no standards, and everyone did things their own way (including me), and I had to study each new program before making any significant changes.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
Most modern programming environments do enforce coding standards. We use Eclipse, and have project-wide format standards. As for it being a 'coding standard': I've always considered coding standards and formatting standards to be different things. Code reveiws are for coding standards, not for picking nits on whitespace. That said, you don't submit your code for review until you feel it's ready to submit it to the revision control system, so i don't know why you still have whitespace issues in your code.
Of course there are no studies because everybody just KNOWS it matters.
I switch between javascript, C#, html and sql all day long, and once in a while some php. I can even deal with minified javascript if I have to.
Coding standards are to reduce the chance of bugs. They are not bugs per se.
Coding reviews are worthless in most situations. People look for coding standards violations more than they do for the error the standard is trying to prevent.
Tools should be written not just to look for violations, but wherever possible, look for the bug the standard is trying to prevent.
I also recall humerous "dualing checkins" where two guys, using different tools, kept overriding each other's coding standard fixes.
One kept adding a default case to a switch because the standard demands it. The other kept removing it because it was flagged as unreachable because all possible cases had been handled already.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
If it doesn't have an auto format you can tailor to the company standard get one.
Alt shift f is your friend...
http://www.awfullybigmoustache.com
I saw this story very early this morning.
Regardless of the reason for it being posted, it's a good conversation to have.
I think that consistent coding style is extremely important. There's a heck of a lot of sacred cows and third rails out there, when it comes to exactly what those coding styles should be. I'm not comfortable dictating to others what is best. I think that is likely to defeat the purpose.
Unless you feel like nursemaiding your own code for the entirety of your career, then using a consistent style is directly to your own benefit, as that means that you can easily turn it over and move on to newer, more interesting things.
In my own experience, developing a style (which includes commenting) is something that quickly becomes rote. You don't even think about writing good code. It just happens.
Pascal was developed as a teaching language. It enforced a certain level of style. Python enforces it even more, by doing things like insisting that whitespace be spaces, and that indents make a big difference in terms of context and scope.
When I became a C programmer (after using Pascal), my style quickly degenerated into Caveman Gothic. I had to re-learn a decent style.
What helped me a lot, was using Doxygen. It's a fantastic utility that helps turn comments into documentation. I had used HeaderDoc and JavaDoc before, but they never caught on in my workflow. Nowadays, pretty much everything I write is Doxygen-commented. I actually feel physically uncomfortable when I write code without Doxygen comments (like a quick one-off test function).
Working on a team helps. Having someone come over to you every two minutes, asking the most simplistic questions, trains you to write "leave me alone" code.
Once you've been writing consistent code style for a while, you don't even think about it. Even my quick n' dirty routines are extremely well-structured.
I have a certain style, which involves things like function and class names, variable and data member names, indenting, use of certain language primitives, etc. It is not ironclad, but I find it flows pretty naturally.
"For every complex problem there is an answer that is clear, simple, and wrong."
-H. L. Mencken
If the stylistic issues are likely to cost significant effort down the road, they need to be brought up.
It may be better to bring them up 1-on-1 with the developer, but they need to be brought up.
On the other hand, if "non-standard" stylistic issues won't cost significant effort down the road, then I agree, drop it.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
One day, if you work hard enough and get your stuff done, if you impress people with dedication and skill all the while letting the unimportant things flow as water under the bridge, you will get to make the rules. And when you do, I hope to see you asking Slashdot in a new context.
Is to achieve this: http://www.joelonsoftware.com/articles/Wrong.html -- make things that are wrong be more obviously wrong. Using discipline and coding standards is just one part of the appropriately paranoid developer's defensive programming toolkit.
Coding standards are important. What you're describing is much more code formatting, most decent IDE's can accept coding templates that will allow the auto format feature to conform to your company's formatting standards. When I think coding standards I think, defensively checking for null values, not chaining method calls, always using braces with if statements for java users and keeping code complexity as low as possible while meeting the requirements. The goals of coding standards are to keep code human readable and avoid common pitfalls of bad coding habits. Besides, you should take pride in your written code and make it as presentable as possible.
There is no memory shortage. yes I have heard of XFCE. Go away.
man gofmt
In many shops, this will generate an error:
'man' is not recognized as an internal or external command,
operable program or batch file.
C:\Users\Programmer1>
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Pretty much everyone here has already said it. Coding standards to help productivity, but its a group thing. ie: its more of a a +3% to +5% gain for everyone who has to share code and know what the hell is going on. Coding to a standard that is not a habit for yourself is going to be a bit of a hit to your own productivity.
So if you hate dealing with the existing code standard, you could either implement a script to do the reformatting for you, or you can find an existing tool to do the same. Write however the hell feels natural, and when its working, run the conversion script and retest. If possible, convert in both directions (ie, go from official standard to your preference before you start modifying it again). It wont help structural issues (ie, if using certain design patterns is forbidden), but it will deal with the camel case vs underscore, variable name prefixes, space vs tab, and where the hell to put curly braces.
END COMMUNICATION
I don't think you know what a "coding standard" is. It's not just formatting.
Excessive forking causes un-wanted children.
Yes. Good. And Eclipse helps format your code as you type it.
But . . .
You can still have format wars, but automated and invisible, and probably inefficient for the source control system. So everyone needs to import the same formatting settings into their copy of Eclipse. Or make that file part of the project.
There is or should be more to coding standards than mere style. How about things like making methods static if possible. Not making something public unless there is a reason. Keeping local variables within the smallest possible scope, etc.
Some of those kinds of rules really CAN have productivity gains for other programmers who have to read and comprehend code written by someone else.
I'll see your senator, and I'll raise you two judges.
Ezekiel 23:20
LOL, talk about taking things out of context!!!
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
As other have pointed out: Yes.
But if you're spending time trying to remember coding style semantics, and others are spending time correcting you... then you're doing it wrong. Spend half an hour setting up your editor to automate spacing, formatting, etc. If your editor can not do this, then find a better editor.
Additionally, require code to pass some sort of automated style check (like cstyle) before check-in. It might require a little initial setup, but it will save a ton of time in the long run.
I'm writing Python in Sublime Text 2 and use the SublimeLinter plugin. Follow basic coding standards like Python's PEP-8 or pylint is trivial as uncompliant code is highlighted as I type. When it's so easy to comply, why on earth not?
Dewey, what part of this looks like authorities should be involved?
It's been a while since I read _Code Complete_, but I believe it does cite a number of studies suggesting productivity increases with certain coding conventions. But not all conventions are created equal. Having everyone use the same indentation is essential, and does hurt productivity when it isn't adhered to. Naming conventions make code tidy and more predictable, but in my experience does little or nothing for productivity. Others are just nitpicky and useless - for example in a previous job, the expression in all return statements was required to to be enclosed in parentheses - or even just plain stupid, as Hungarian notation in Java code (all objects have an "o" prefix, integers have an "i", and so on), this also in the same company.
why don't our tools enforce these standards automagically?
They do. Almost every modern IDE will format to a standard and mark code that is not to that standard. Tools like "checkstyle" can document code that is not correct during the develop or build phase. That is why no one is wasting anyone's time here having a corporate standard. Comments about how many hours where lost "picking nits over whitespace" tell the story of developers who are too uninformed, ignorant or more likely self important to follow simple guidelines that for the most part can be automated. These are exactly the type of developer I want no where near my code base. If they won't follow the style standard they sure a f&*$ won't use the DAL as intended or follow the MVC standards. They are the developers who spend 1000 hours generating their own XML parser because they don't like they way DOM or SAX work. Having a standard does not waste time, but the kind of developer who won't follow it does.
No sigs in BETA. Beta SUCKS.
Resharper does this for you. Learn the standards. Set them. Autoformat. Done.
"How Experienced and Novice Programmers See Code
From one of the links:
-Eric Holk
Viable Slashdot alternatives: https://pipedot.org/ and http://soylentnews.org/
Its like reeding slashdot. Ewe come a cross sum one who can barely spel, has trouble with homophones, puts extraneous apostrophe's in, and it makes it much harder to read four some one whois used to reed. The same goes four codine. If the reviewer C's a bracket where he accepts a curley brace, even though the too ar interchangeable, its going two slow hymn down.
Their, fixed that four ewe.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I should clarify that I'm quoting Eric Holk in that comment. I'm not Eric Holk.
Viable Slashdot alternatives: https://pipedot.org/ and http://soylentnews.org/
I've always felt there should be a plugin to source-control that automatically formats source files at check-in.
Apply the rules.
If you have better rules push for them.
If you just don't like what was chosen tough - comprimise. It's not your own project when you're working in a team.
I do pick these things up in code review. You know why? Because if you can't be bothered to do the small easy stuff that makes my job as a reviewer easier what kind of impression do you think I'm getting of how much effort you're putting into it? This is brown M&M territory: http://www.snopes.com/music/artists/vanhalen.asp
"The legendary "no brown M&Ms" contract clause was indeed real, but the purported motivation for it was not. The M&Ms provision was included in Van Halen's contracts not as an act of caprice, but because it served a practical purpose: to provide an easy way of determining whether the technical specifications of the contract had been thoroughly read (and complied with)."
Do Coding Standards Make a Difference?
Yes.
We live in the future, why don't our tools enforce these standards automagically?
Eclipse has had a configurable code formatter for ages. I would be surprised if other tools did not have this feature.
Free Manning, jail Obama.
There have many suppositions expressed here that I don't entirely buy. However, interpersonal dynamics can quickly become so rancorous that it's simpler to comply to Mao's dress code than stand apart as an artisan.
The most important aspect of code is the thought process involving in convincing yourself that the code is correct. It hardly matters a whit is the person reading the code reads the code but fails to read the argument embedded in the subtext within the presentation about why the code actually works.
C++ is a multiparadigmatic language. Some people hate that. Nevertheless, it can be heavily object oriented in one place, and completely generic in another. I don't find myself that any single formatting standard best emphasizes what matters to code correctness across these styles. Scope in generic code is mainly lexical. Scope in algorithms is mainly flow control. Should one automatically format the braces in the same way? Isn't that kind of like insisting that every knife has the same grip? You know, the standard rubber handle that everyone expects to feel the same way, no matter if it's a sushi knife or a steak knife or a bowie knife?
A more severe coding standard might go all the way to specifying that every knife is sharpened with the same bevel (either double or single sided; if single sided, either left or right handed) and to the same bevel angle. Steal is steal, ya know. German, Japanese. WTF, who cares? Ditch all the bread knives. Those are just weird.
I'd desperately like to see a study into whether rigid consistency leads to certain classes of bugs, because all eyeballs nod in agreement over the dress code. It's certainly true that people working on the code base who get used to the style will have a nice comfortable feeling. That could have good effects on code quality. But it could certainly also have bad effects that are harder to notice. Heaven forbid anyone rains on the cozy picnic with actual data.
Utopian for Beginners
This article is interesting but belongs to the TL;IRRO category (too long, I'd rather remain oblivious).
Why don't we regiment thought, too? The ideas expressed in code would be so much more transparent if we all though about the world in the same categories.
If you have messy code, it means you're not taking pride in your work, and besides, why should the rest of us have to look at that mess? Car analogy: a '68 Mustang the color of bondo. If you can't bother to paint it, it suggests maybe you didn't bother to tune it up either.
An especially good style guide will also include rationales for why they chose particular ways of doing things. A good example is the Ada Style Guide (it's an industry standard).
http://www.adaic.org/resources/add_content/docs/95style/95style.pdf
Don't loose hundreds of hours in code reviews. Just stick to the style guides and avoid discussions. Your code will look better and will become readable to others. You make friends. And you practice basic politeness.
I code since late 70s and believe me, your algorithms most likely aren't really that hot. Write-only programs suck.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
... you wouldn't be asking this question.
I'd say no, coding standards are pretty pointless, unless people are being deliberately difficult or obsfuscating.
In my experience people in large companies like to write them because it's an easy thing to stick on their PDP.
"XML is like violence. If it doesn't solve your problem, use more." - Anonymous Coward
Malbolge is the revolutionary new answer to the tyranny of C++!
Sadly, a style guide has yet to be developed for this amazing engineering feat.
The brain trust on Slashdot, however, should make short work of rectifying this appalling situation.
"For every complex problem there is an answer that is clear, simple, and wrong."
-H. L. Mencken
See, the flip-side is:
I don't care how good your algorithm is if it's written in an obtuse, unmaintainable manner.
There are plenty of coders (especially those new to the profession) who don't understand the value of tidy code. The smart ones quickly understand and tend to ask for some tips. That's the first (and for me, primary) reason for having a Coding Standards document.
The second reason is to reduce friction when viewing each others' code. Local vars should be 'someVariable'. Instance vars should be '_anotherVariable'. Methods should be 'SomeFunction'. I physically twitch when I see underscores in variable names.
But, a Coding Standards document should be clear on 'must-do' vs recommendations. We state that you should split multiple-clause IF statements tidily to avoid excessive horizontal scrolling. But we only provide recommendations on how to do brace placement.
Every single point in a Coding Standards document should have a defensible reason to be there.
Our CS doc is in a Wiki which lets us have a comment section for each page (and there aren't many pages overall). If anyone wants to ask why something's in there, or suggest an alternative, they're free to. The doc's existed for 9 years and is largely unchanged other than to add explanations and extra languages. We most recently added some docs on SQL stored procedure styling, since ours were abysmal - copying and pasting SQL from Management Studio's view designer is a 'go back and do it again whilst we laugh at you' offence now :)
What's the frequency, Kenneth?
In our shop we take on a lot of code from other firms and our rule is always "write your code in the style of the author if you can". Keeping it consistent on a per-project basis is a good rule of thumb.
For projects that we develop in house I tend to encourage the Allman style and I've setup our IDEs to perform, with a key combination, automatic formatting. That way, before you commit you hit the key combination and BAM, formatted code. I think someone playing the heavy on where you put your braces or white space should have a beer and chill out; I'd be more concerned with what the code was doing rather than it being presented on a silver platter.
If you don't comment your code you're a savage, though. :D
"It's here, but no one wants it." - The Sugar Speaker
The places where I worked used a simple guide line: the author has to clean up trivial issues before submitting an item for review. In case of code, this means ensuring style conventions.
Which in practice is trivial for reasonably popular programming languages:
First, you rarely have to invent your own style conventions. Instead, use existing standards. For instance, there are standard coding conventions for Java and Python.
If some guide lines do not make sense for your shop, simply change them to fit your needs. For example, PEP8 recommends a maximum line width of 79 characters. However, all our developers work a horizontal resolution of 1920, so we allow 132 characters. We also changed naming conventions from the loud and baroque SOME_CONSTANT to the calm SomeConstant.
Next, there are tools to check these conventions such as CheckStyle and flake8. Often you can even find tools to reformat source code consistently or automatically fix trivial issues like missing blanks, for example autopep8.
Some shops inject these tools in the commit hook of their version management and make it reject any code that does not conform. Baring that, the review moderator is required to run the style checks on the review item. If it turns out that the author still left style issues in the code, the moderator returns the item to the author and requests to clean it up.
That way, the reviewers always get tidy code and can focus on comprehensibility, maintainability and algorithms.
.
It has always been explained to me (by the zealots) that the "joy and beauty" of Java (and Python) is that . . . "You don't need to write lots. Someone has probably already done that, just reuse their code."
.) Be it a good or a bad standard . . . if each language at least proposed a preferred . . . then you have a shot at all the independently developed API's . . . utilizing the same format.
Fine, so I get the, lets see . . . Windowing API from vendor_A, the DB API from author_B, and the Serial I/O API from freewareProject_C.
Great, now all I have to do is write the core, and utilize the API's that have already been written.
But vendor_A used WhatYouCallCamelCase, author_B usednocaseatall, freewareProject_C used_under_score_variables.
Now your central core, must reference/utilize variables/functions/objects/etc . . . of all three types.
It'd be nice . . . if each language (like the K&R book did for "C") at least suggested a Preferred Standard Format.
From my own experience (or just read the preceding 800 posts) indentation can become a holy war. (Seriously, I don't see how Python survives more than one coder's reformatting . .
Then, your core and all its references are at least "consistent" for pure visual readability. Allowing you to focus on "what it does" not "how it looks". It also has a "shot" at depersonalizing the choice. ("I know you like it like that . . . but we try to adhere to the Preferred Standard here, so . . . though I'm very sorry it disturbs you, my hands are tied." Yes, its a cop out, but it can be utilized as an argument deflating position for the better of all.)
No, I don't remember your name. But the memory mapped screen on a TRS80 from 1977 is from 15360 to 16383 if that helps.
Whether coding standards really matter for maintainability generally depends on how much information you expect to be carried by the formatting.
We generally assume that indentation follows block structure, so indentation standards tend to be very important. I've wasted hours over bugs that were hidden by incorrect indentation.
Naming conventions may matter if the coding standard dictates a different styles for different scopes (e.g. LeadingCapital for global names, etc), or if type info is embedded in the name (pszFoo, lBar, etc).
Beyond that, coding standards help readability but that's about it. That may or may not be an issue depending on the team involved; one benefit of a uniform look is that you get less of "You're stuck fixing that code forever because I can't read it".
Whitespace standards (outside of indentation) are generally of marginal to no use IMHO. I'd follow reasonable whitespace standards, just for that uniform look, but nobody should be spending hours on it. The fancier the coding standard, particularly as it applies to variable naming, the less useful it is in general.
You shouldn't be losing "hundreds of hours" in code reviews, though. Either you're deliberately being obtuse about things or your coding standards are insanely complex, or uselessly ambiguous. There are a number of things I don't like about the coding standard I work in now, but I stick to it anyway because it makes the code more uniform and easier to read. Have you tried doing the same?
Over the years I've seen code that has followed one standard or another, and more than my share whose only rehabilitating feature was the fact that I could tell it was a cut-and-paste mess produced by someone who frobs rather than tunes an algorithm. Clean consistency, irrespective of the particular style, has always determined my reading comfort, and therefore understanding of the code, far more than blind and across-the-board style-naziism. That and the generous application of vertical whitespace to delineate significant blocks of logic.
When I work on my own code, I use my own preferred style. If I work on someone else's code, I do my best to adjust to that style because I'm awesome that way ;-) or maybe just respectful of other people's preference, as I would like others to treat my style with equal respect.
--Udo.
For any project with more than one or two developers, the more important part is the general layout of the project. Which stuff should go into which packages and even into which layers.
For example the most annoying thing I encountered was one project I inherited (and choose to ditch and re-write quite soon) was where someone had used the database layer for some calculations, the middle tier for some similar calculations, and even the client side for others that where basically duplicates of the ones already present in the database layer.
It's not just formatting.
Thank you for that. Indent and bracket placing standards are good for consistency, xCase and whatever are nice so that one immediately recognizes variables and functions and whatnot, but the really useful part of a coding standard is the one that says that every function has documentation block which specifies:
- expected behavior .)
- allowable inputs (NULLs, empty strings, corner cases . .
- allowable outputs
In the Java world are dozens of tools to enforce coding standards or at least give visual clues if they are broken.
Checkstyle or Findbugs etc.
However I agree, in my last project we had far to many nonsense rules. But you are not hindered by them often.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
a style guide has its merits in that it is probably easier to pick up on what is what if you follow some conventions. However, a guide must be strictly that, and not an absolute law which has to be checked and rechecked all the time. If you find code (eg. when you have to change something there) that doesn't follow your guides, refactor it, but don't waste useless hours hunting for the obscure corner-case. Also have your IDE do the checking for you and simply mark common "errors" like wrong variable naming conventions as warnings in the code (and have your build fail if you have too many warnings).
If you can't follow a simple style guideline, what does that say about the rest of your code? When reviewing code, if I start to see a pattern of not adhering to the coding standards, I'll kick it back immediately. Why? Well, if you can't figure that out, then I don't expect you can figure out whatever algorithm you're working on either.
Coding standards are in place to enforce consistency throughout a code base and to save developer time. When reading code, you shouldn't have to be scanning for how things are indented or whether or not a bug is caused by a dangling else, you should be able to focus on the code. Looking through inconsistently formatted code takes additional time and effort - not much, but scale to a few thousand developers over a period of years, and that's a serious amount of wasted effort.
As others have said, if you want to write code your way, do it on your own time.
"I am Dr. Freud, but you may call me.siggy."
...a poor standard can drag everybody down. One of my pet issues right now is a structure that exists as code, as XML and as a database structure. Except code has namespaces, classes/objects and attributes, XML has a schema with elements and attributes with namespaces and database servers have schemas, tables and columns. So when I store an element in a table, I should now call it a class... logical? Not to me, but we're at least trying to be consistently illogical so you only need one code book to decipher it.
Live today, because you never know what tomorrow brings
It is a heck of a lot easier to read code which is consistent, and it matters much more that it's consistent than which particular standard you use.
Badly-formatted code is much better at hiding errors. If you want a starting point for learning some of what's going on, check out Kahneman's Thinking, Fast and Slow. But long story short:
1. If I see badly-formatted code that ignores coding specs and the like, I generally start with the assumption that whatever I'm chasing down will be in that code.
2. This is nearly always right.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
Plenty of people above have posted good justifications, but pragmatically it's also painless to implement good standards. If you use visual studio, the amazing tool known as Resharper will do the style checking and correct casing and spelling for you. Since an independent third party is taking care of this, it will reduce squabbling and "hold outs". If you're cheap, there are other free tools (including the Code Analysis which comes with visual studio). If your PHB wants a published doc, just point to a decent existing standard, like the Microsoft-generated naming guidelines and coding conventions There are similar tools and published conventions for Java and C++. This is a no-brainer folks, and plenty of talented individuals have tackled this problem. Once it becomes part of your infrastructure, you can even skip most of the code reviews for naming conventions and coding style.
"Worker bees can leave
Even drones can fly away
The Queen is their slave."
They're useful if you have multiple error conditions...just goto an error cleanup path. Also useful for skipping to the end of a loop but where you still want to do something before the next iteration.
See nohz_kick_needed() and distribute_cfs_runtime() in at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=kernel/sched/fair.c for examples of each scenario.
I usually add a definition of "TLA" just to see who's paying attention.
If someone is writing new code in the middle of existing code, and isn't matching the style of existing code, I'm *absolutely* going to bring it up in the code review.
Totally brand new code should follow the project guidelines.
Otherwise you get stuff like what I've worked on where you could tell who wrote what code because everyone used a different style.
Microsoft Visual Studio has a fairly well agreed upon way of doing this automatically with StyleCop, http://stylecop.codeplex.com/
It's good as an educational tool.
Play Command HQ online
You never know, but the code reviewer could use whitespace and other coding convention rules as an easy way to check if you're a careful programmer.
As in the old bowl of no brown M&Ms required in the Van Halen contract. A quick and easy way to tell if the concert organizers were being careful to follow all requirements and safety conditions, the band hid a requirement for a bowl of no brown M&Ms deep in their contract.
If the bowl wasn't there or had a single brown M&M they'd know the stage and lights setup was potentially life threatening and immediately cancel the concert.
If you can't be bothered to follow naming conventions, brackets and whitespace requirements... how can they trust you to be a careful developer?
Cwm, fjord-bank glyphs vext quiz
Coding style is about seeing and avoiding bugs.
There are a few errors in these blocks of code. In which are they easier to find?
var inStyle = {
j: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit'
, k: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit'
, l: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit'
m: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit'
, n: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit'
, o: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit'
, p: 'taciti sociosqu ad litora torquent per conubia nostra,'
, q: 'Aenean non purus et dolor adipiscing blandit at sed tellus.'
}
var soNineties = {
j: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit',
k: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit',
l: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit',
m: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit',
n: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit',
o: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit',
p: 'taciti sociosqu ad litora torquent per conubia nostra'.
q: 'Aenean non purus et dolor adipiscing blandit at sed tellus.',
}
The compiler/interpreter will catch them for you but that just slows you down.
ayottesoftware.com
read the style guide and actually follow it? That would save you the time of being corrected and the corrector the time of having to correct you. I've never seen a style guide that was too long or complicated to easily follow. You can get used to just about any style once you've worked in it and looked at it for long enough. Consistency does actually go a long way towards readability which is a definite productivity gain. You can also glean information about code from the naming conventions without even thinking about it as long as they are consistent.
FTFY.
Jherico
What can the average user can do to ensure his security? "Nothing, you're screwed"
Variable naming standards reduce the guesswork when referring to variable.
If it is all caps it is a constant and can not be changed.
If I am in some code and I need to modify or refer to the variable that hold the "total cost" it could be total_cost, totalCost or totalcost depending on how the programmer declared it. With a coding standard there is no guess work. There would be only one choice.
If the first letter is caps it is a class name and the method is static. I don't have to check.
I need to access an instance variable, Is there a get and set method? What does the standard say?
Wasting hours on code reviews is caused by people refusing to follow the standard. It is a people problem not a standard problem.
Just because it is a standard does not mean it is a good standard. There are bad standards that do cause issue but some people love them. Coding standards are a balance between pedantic nit pickers and wild free spirits. Do I really care is there is a space after the semicolon in a for statement? No but I do care about an if-then-else statement on one line. Consistency within an organization is very important. I call it "hit by a bus" theory. Code should be written so that if you are hit by a bus someone else can read and understand it.
The issue is that what one programmer calls common sense another will call stupid. Standards create consistent code and good standards create readable code.
We've got a simple coding standard here with things like member variable prefixing, file naming, spacing (4 spaces, no tabs), etc. When you go into existing code you know what you're looking at and when you start writing a new file you don't need to decide about this_naming vs thisNaming vs ThisNaming vs GetThisItem vs thisItem vs etc. etc. etc. And you can grab the standard file header and drop it in. All in all, it saves a lot of time.
On the other hand, we're not pedants and don't dictate brace placement or otherwise care about whitespace like 'if( this )' vs 'if (that)' because that's not a major impact on readability or editability. If we really cared we'd just have the code automatically reformatted on check-in. You just need to work with professionals - easier said than done, I know.
If you've lost hundreds of hours because you didn't respect the coding style to begin with, imagine how the other guy felt reviewing your code.
If you didn't get the message after the first few hours, it's amazing they wanted to keep you around. You're obviously not a team player.
Doing it the first time is fine. Doing it the second time, well, it happens. After that the fact that you insisted on sending in bad commits or patches is frankly insulting to the rest of your team.
It's funny that you call the others pedants when really, insisting on delivering non-compliant patches or code is the real pedantic action here.
Why are you so surprised that no one looked at your amazing algorithms if you couldn't get one of the basic principles of the social aspect of coding right ?
If you can't follow the beginner's instructions, why should anyone trust your algorithms are amazing ?
Code isn't automatically better just because it flaunts social agreements, just as you don't become as good as Linus Torvalds by being as abrasive as he is.
I'll give you a coding standard that's worth having: use a prefix to clearly identify your module statics and globals. If in an OO language, your class statics and member variables, too. If I'm looking at your code and I see an assignment to a nonlocal variable, I shouldn't have to go off analyzing the entire source tree to find out what it is.
Michael J.
Root, God, what is difference?
Comment removed based on user account deletion
What is this "code review" you speak of?
giggity
In another place I worked at, there was perhaps only a dozen coding style items, every developer had their own style of working, and the crazy thing was it worked. You got used to the other coders' "accents" after a while, and the good thing was you didn't need to think too hard about the coding standard, nor waste much time in reviews.
So yeah - it depends.
I agree that standard coding techniques are a good thing. I prefer however to focus it towards and existing file or module. If a file was written in a given style, follow that style. It makes the file readable.
Generally I have found that working with a pile of libraries written by third parties, there's no way you can be sure that you'll have a full product with a single given coding style. So, you're already used to calling outside of your own module using alternative coding styles. But when you mix the coding styles heavily in a given file and worse, in a given function, it becomes unreadable.
Things can easily get carried away of course. If you look at gstreamer, the variance between modules regarding coding style is a nightmare. Product is great and I always enjoyed working on it, but there's so little consistency in the system due to being overly complex that some people will do the bare minimum to get their code working with it and then just code an entirely different way after that. It would have worked better of course if people would make an attempt to move their integration code into a separate file and make the transition between files instead of strictly between modules.
I'm hoping at some point that tools like swing will also allow making borders between like languages to have a method of enforcing coding style at the edges of modules.
True Story: Consider these two rules...
(1) Getters and Setters must be used for all local varialbe access.
(2) No function may be defined within the class definition body, and must instead be in the corresponding translation unit. (in C++ terms, you have to put all your member functions in the .cpp file and not the .h file etc.
So now every get/set operation (e.g. a register load or store) is turned into a far (inter-moudlue, cross translation-unit, unoptimizable) call, with arguments, stack frame, etc., to a remote function to do the register load/store.
Create a variable with that microsoft horror where you prefex the variable name with its type "lpszFileName" (long pointer to zero terminated string named FileName) and then change the underlying type after you have written all the code so that some long pointer to int is now a long pointer to a long but it still says int, or is now an opaque 16-bit value instead of a pointer at all but the names in countless blocks of code still lie.
And as far as the whitespace thing, I have a unicode non-break space with your name on it, particularly if you write in Python.
Coding standards that are _dumb_ can be _incredibly_ _dumb_ in many hidden ways.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Most "coding standard bugs" are hidden in a meta-level of reasoning that is harder to find than solving actual crap code.
True Story: Working at a medical equipment manufacturer writing C++. These two atomic rules, placed far away from one aonther in the standard made a mess. See if you can spot the mess.
(A) No member function may be defined within the class definition, and instead must be defined in the translation unit for that class. [e.g. you have to put the member definitions in the .cpp file not the .h file, so "class X { ... void foo() { /* implementation */} }; is not legal.]
(B) Access to member data may only take place via "getter" and "setter" functions. [as opposed to putting the varialbes in the "public:" part of the class.]
Both harmelss enough by themselves. But I opened a crap-ton of bugs on this issue because the two rules taken together turned simple register load/store operations into unoptimizeable far calls between translation units for each get/set operation. So I put my getters and setters in the class definitions like a sort of sane person (I didn't try to force sanity on them complely and just make some of the trivial values public, as I don't think they could have taken the strain) and, as required by the version control integration with the codeing standards enforcement and bug tracking tools, I filed a request for exception for every single damn such usage and let them choke on their procedure.
But there was a reason that only _my_ code didn't run over its CPU time budget.
A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. -- Emerson.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Standards and enforcement of same is (usually) a symptomp of the "interchangeable morons" school of management. It presumes that all problems have a (ayn rand-ish) uniform solution that all _programmers_ will process identically.
A small number of "do not do"s with a "unless you have good cause" _guidelines_ are reasonable, but something as firm as a "standard" is a great way to make your great programmers no better than your worst over time.
Standards often contain bugs themselves. Things that create a hidden cost on the programmer and the program that can bog both down.
examples:
Even Microsofte eventually abandoned their "Standard" for putting the variable type as encoded dirt on the front of their varialbe names such as "lpintThingy" having plagued their code with Thingies that are no longer long pointers to integers and that cannot be globally searched and replaced because that hazards destroying other code.
Combined rule failure (use getters and setters + don't put member function definitions inside of class definitions => what would be a register load operation becomes an optimization resistant far call across translation units ** every dang time you set or read a scalar).
If you cannot trust your programmers to write good code then making them format it so it _looks_ like good code is a wasted effort.
If you cannot trust your great programmers to write great code eventually they will stop even trying to do so and you will be left with a hassle avoiding idiot or someone looking for a new job.
If you cannot trust your new programmers to understand your previous code then your new programmers are probably inferrior to your older coders.
If you are not winnowing out the _bad_ programmers via rational code review then your management is useless.
All but the most rudimentary coding guidelines are productivity and creativity and performance murderers.
Every company eventually realizes this, on and off, for a while, each time a management team ages into a job, and then forgets it again when they hire new managers.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
I have worked on projects that loast hundreds of millions of CPU cycles because the coding standards encoded individual ideals into runtime performance killers. (the example I have placed elsewhere is "must use getters/setters" and "may not put function defintions inside class definitions" turns "class foo { int X; ... int getX() const {return X} };" (which can be optimized down to a register load) into a (not optimizeable at all) far call from each point of use into the foo.o (object file) after a potential PIC (position independent code) fixup for a shared library.
And this stupidity can waste a _lot_ of man hours. In order to get my part of the medical device that _that_ coding standards bug was written under, to run in acceptable time (e.g. to not overuse my CPU time budget in a freaking real-time heart monitoring ap) I had to break the coding standard and put the getters/setter (or occasionally the plain "public" variable) into the class definition anyway, then run it into the version control system, then go through the "naughty programmer" output list and create a bug report for each such optimization and assign that bug to that "naughty naughty" message. Then the bug review team had to deal with those bugs. Then the code review team had to approve those optimizations.
Even with this only costing me a couple of hours on the one set of modules, when you consider the ten or twelve people that the automation systme then had to nag, and the hours _they_ lost. you get into a lot of wasted time over all.
Now add the part where once every _other_ programmer who silently followed the automatically enforced rules ran over time-budget for their code (so the system was too slow), and all _their_ code had to be fixed once everybody noticed that _mine_ was not so plagued.
Then the cost of the project running late and eventually being determined to be "not worth the effort being expended" and getting canceled outright...
Well, truely hundreds of man hours and _many_ thousands of dollars were wasted on a project that was largely killed because all the programmers were muzzled into paralysis by a huge steaming pile of these sorts of pointless restrictions (many of which would have been good for a _class_ in programming but most of which were _toxic_ to a real project).
Well, you know, there are reasons that failed projects fail, and sometimes those reasons involve over-regimentation of the otherwise creative process of finding solutions and expressing those in code.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
For most of my career I was one of those programmers who clinged to his own particular style of coding. I got away with it because I used an IDE that could rearrange other people's code into my style for me to work on it and then put it back in the other style when I was done.
A few years ago I spent a lot of time studying new stuff on my platform where all the code was written in a style I didn't like and that I had always told myself made things harder to read.
I got over myself as a result.
I think I became a better programmer by reading code written in different styles.
I now think it is the mark of a provincial thinking to cling to your own style at the expense of good relations at your job.
If you write code strictly on your own, you probably don't need a document, because - if you are a good programmer - you already have a style.
But as soon as you work with a team, you need a document. Reading code written by others, understanding what it does, spotting bugs and a dozen other things are just so much easier if everyone uses the same style and that style makes sense and was written to support good code, not just some arbitrary orderliness desire.
For my main project, our Style Manual is about 3 pages, including examples. Also, we don't fuss over minor details, many guidelines are that exactly - guidelines. Many are "should" rules, because we realize that there are some cases where an exception makes sense.
But yes, it was worth it and it helps. When you have a team, a style guide is very helpful. But like all things, it can be overdone, and if someone whines about whitespaces, for me personally that's the point where it becomes crazy. Heck, your editor probably has a "reindent everything" command. Use that, done.
Assorted stuff I do sometimes: Lemuria.org
Why do all soldiers have to have the same haircut? It's about reducing individuality and being assimilated into the squad.
Sticking to coding standards reduces the sin of code ownership.
Whitespace used to be a big deal. Certainly with RG8, Fortran, lesser extent Cobol. Real languages it isn't so important. Standardizing how things is done is. So when I call something that was written by another group, I expect it to return something like our group has. Same type structures and so on. They should make sense. Otherwise it will introduce errors. Errors that can be exploited or errors that cause unpredictable things to happen.
Today I write my stuff such that any idiot could look at it and use it. That's because in 10-15 years I might be that idiot who needs to fix something. What was I thinking? Oh yea - here it is. Over the years I've been complimented for how clear my stuff is.
Whitespace can be fixed quickly by the way. Just use an editor like Emacs that supports ws macros. Set it up, tab and it's where it's supposed to be. Just set up a macro and Whoosh! It's right. I'm sure you could also use perl or C with the right program.
(Macro in emacs - control-x left paren. This example - escape (top of file), control-x leftparen (define macro), control-n (next line), tab, control-x rightparen (end macro). Control-u 5000 control-x e (execute macro 5000 times). Macros can be very powerful.
Python has PEP-8, which is followed pretty well by most projects.
-- Lattyware (www.lattyware.co.uk)
Stop coding like shit, then. Adopt your organization's coding standards, or lobby to have them changed if they're dumb.
pr0n - keeping monitor glass spotless since 1981.
Comment removed based on user account deletion
They will until we all use editors that understand canonical representation of the source code and restyle it according to a personal preference.
As a software developer for more than 15 years I'm amazed why we still used this archaic system of writing text for developing software.
In any large project or any highly-regulated project like medical equipment, this is exactly the right way to do things.
The only change I would've made would be to start the bureaucratic process of changing the coding standard itself to explicitly allow or even recommend that "simple" getter and setter functions go in the .h file, for the very reason you were doing it.
Because this is a medical equipment setup where people can die if things go wrong, I would err on the side of caution when defining "simple": Basically, if it's a simple copy operation of a simple data value that is obviously bug-free by inspection (well, as obvious as anything can be "by inspection" - which is to say 99.9+%), it goes in .h, no questions asked. Otherwise, either put it in .cpp or request an exception. The idea is that by requesting an exception, more eyeballs will look at the code.
If this wasn't a "people can get killed" scenario, I'd be a lot looser with standards-enforcement.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
... testable requirements, and executing those tests, are much more important and come first. This is the big secret that separates the engineers from the hackers If requirements and tests are in place, then standards are useful, otherwise they are a distraction.
I did try to get the coding standard fixed.
Meanwhile, elsewhere in the code, in full compliance with the coding standards I found:
(1) unconditional static down-casts from base types to derived classes despite the possibility of error event classes being the return value. (e.g. class A, A_failed, and B, where B and A_failed were derived from A, and then a key static cast from A* to B* without any check for A_failed at all.)
(2) shaving down (bit shifting and masking) pointers through a void* arg and then into four bytes (char) that were then pushed into a byte queue, where they were later popped off as four bytes and shifted back into a pointer some type. (The "real time programmer" who came from a VX works background didn't believe in just making an array of void* and moving all the bytes at once for whatever retarded reason.) [also broken because the A* to void* to B* three-way conversion isn't necessarily safe since it should be cast to A*, reinterpret_cast to void*, then reinterpret_cast to A* then dynamic_cast to B* to be safe and symmetric.]
(3) so many unsafe operations at in the module call prototypes that I eventually just made my code "correct" (e.g. call-safe) then put a conversion layer that used the unsafe API in both directions and called that translation unit "unsafe.cc" and had lots of forwarding functions spelled out why the calling convention was flirting with disaster so that all the unsafe calls and unsafe casts were all in one pile and in one place.
Item 3 was somewhat insurrectionalist because I wasn't allowed to get any of my criticisms to be acknowledged by, or then past my boss who's "it worked when we tested the prototype code that one time" attitude kept things tightly broken.
So we had nicely regimented coding standards but I always look at the brand name of any medical equipment I see sitting next to a bed now because I know what the code base for one particular brand really looks like and how much they didn't give a rats ass about doing things right (as opposed to doing things they way someone decided they should be done based on single test runs).
That guy who noticed that if we build buildings the way we built software, the first woodpecker to come along would destroy civilization? Yeah, he wasn't exactly wrong.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Quoting from your signature:
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Oh, the irony.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
The irony is completely the point of the signature and it's attribution.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
You will understand when you have to work on other people's code. With no time to re-format everything and six other programmers that like his way better.
If you can not do more than one format (or more than one language for that matter), then you are still new. 8-)
But more than one format in a project, is a pain, even if the one they specify is not yours.