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.
Check out OpenStack and their infrastructure tools. For example, they have a trunk gating setup for pep8 and pyflakes for their python code, and it is all opensource and automated.
Just use Eclipse formatter and clean up. Configure all their rules and done.
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?
From the summary:
" 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. "
Aww, baby is whining about inconvenience because baby wants to do things only baby's way even though there are guidelines and standards to follow. baby doesn't like to conform to standards other than his own, even if it means that everybody else loses hundreds of hours having to adapt to his style--which they won't, for long if baby keeps being difficult and stubborn.
-- Ethanol-fueled
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!
At least eclipse has some xml files. Also checkstyle exists.
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?
working with a bunch of developers who all have very different coding styles, its much much easier to read code when it is all in the same format.
I would imagine this is especially true for management that may have some coding background, but aren't hardcore devs.
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.
Coding standards give useful hints as what the other person is trying to do. Yes it can get very silly but when you are tired and working on a tight deadline to fix a critical bug in someone else's code every little bit helps.
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!
Stop whinging and do your job properly, so whoever comes in after you can get on with their job and won't feel the need to post your shithouse code to http://thedailywtf.com/
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."
For my C projects, I love "indent -kr -ut -i8 -l120 -lc120 -sob -bad -bap" :)
Makes any C code instantly readable to me
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/
What's wrong with your toolchain that it isn't dealing with most of this?
Your editor should be indenting properly and doing the right thing with tabs-versus-spaces. If it isn't, poke around in the config properties until it is, or get a copy of emacs, which I guarantee can be customized to do whatever crazy thing your company demands.
pylint (if you use python), or whatever the corresponding tool is in your language-of-choice, should be easily configurable to whine about errors like "this function is more than two hundred lines long, you should break it into smaller pieces", or "line contains over 150 characters, should be wrapped", or whatever. I've seen similar tools for c, java, etc.
Nearly every coding style guideline I've seen except camelCase versus underscored_names should be entirely catchable by an automated tool; it should be run as part of your compile process (or unit test process or whatever), so these bugs should never be getting as far as the human pedant in your code review. And variable/function names being in camelCase or whatever should be second nature to you after a week on the job.
If your toolchain can't deal, talk to your manager until you can shake free a few days to write an automated tool to add to your toolchain! Your coworkers will thank you, you'll get some experience with scripting...
In my last job, they passed out a file so that Eclipse would automatically set up the company default indentation (and most other features.) Easy.
There's plenty of code beautifiers out there.Just pick one.
If the comments on the review begin with coding style chances are that you haven't read the patch well enough yourself, otherwise you would have spotted them (and subsequently other possible problems) yourself. It's a sign of a tidy programmer, someone who attends to detail, and as such, it's an excellent self-review of your patch before handing it over to others. On the other hand, it's really something your editor should handle for you, if it doesn't you need to become better friends with it or change to something more powerful.
Yes, they're important. Code styles are as different as handwriting. One person may write with all capital letters, another may use capitals and lower case, someone else may use cursive, another may use a mix of cursive for some letters and print for others. Now imagine having a handwritten book with five different writing styles all mixed up. It makes is far more arduous to read than if you had one consistent style. The key here isn't WHICH style is used. It's that ONE style is used, all the time.
It sounds like your problem isn't that code style fascists are picking on you. It's that you don't use any tools to automatically format your code for you in such a way that everyone on your team has the same style. Our department has specific code style definition files which are used by Eclipse and Maven. These ensure that the style is consistent, and we don't commit a 50-line code update when only one line was a code change, and 49 lines were formatting junk. Having everyone use the same style definition files is important. You don't want your commit log to be cluttered with formatting junk. That makes it nearly impossible to use SVN logs and 'blame' to determine when a piece of code was changed, and why, so you can avoid fixing one bug in a way that creates five more.
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.
As someone who has come into a variety of long-standing projects and found the developers who worked before me did not have a set coding style I can definitely tell you it matters. It doesn't really matter which coding style the developers standardize on, but it matters that you have one. it is a pain switching between different styles, different approaches to comments, different naming conventions, tabs vs spaces.
Once I remember surprising a manager who had originally hinted that I was the second developer on a project when I told her I knew I was, in fact, the forth to work on the project. When asked how I knew I pointed out there were three existing distinctive code styles scattered through the code and none of them really meshed elegantly.
Think of it this way, would you want to read a book/document that was hand written in three different styles? Especially if the lines alternated? It would be hard to get into the flow. The same applies for programming code.
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.
Wow, i hadn't expected the anally retentive crowd to be so big.
Since IDEs these days have loadable code-formatting rulesets it's as easy as having some simple rules in your project.
A - This is the formatting ruleset, it's checked in, use it
B - If you don't like it, make one for yourself, check it in and use it
C - If you open someone's code and you feel your bum muscles tighten up, just pick your personal ruleset and press Shift+Ctrl+F (or whatever does it in your IDE)
And most important, NEVER talk to the project-manager (that would be me) about coding style.
Invest the whining time in writing your ruleset and give me a brake.
Saves a full man-month in a big project.
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.
We live in the future, why don't our tools enforce these standards automagically?"
The Go developers specify an official coding style standard, and they provide a tool to rewrite your source according to their standard. They heavily encourage everyone to automatically run all source through the tool on each checkin. Their FAQ has a kind of amusing take on the issue, which says something like: "You may not like our coding style, but no style is inherently better than any other. Consistency more important than any personal style preference. So deal with it."
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.
Actually your coworkers lost hundreds of hours in code reviews because you were sloppy and did not care about your code being readable. You should fix your code before even bothering them about a review.
Strict coding styles are good because when they are enforced you spend zero time wondering how to name variables or format code. You spend time actually writing good, readable code. This StackExchange question has a lot of insight on the topic.
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
... if you can't spot the troll.
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.
Ever heard of indent and similar?
Just configure them specifications of the project, write your code however the hell you want, and run indent to clean it up before submitting.
Wont help you for naming conventions, though
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.
Last time I had to do this, the "Official Coding Style" started with, "Use the supplied formatting XML file and keep the files in that format." Which, solves all the issues of spacing and braces and what-not. This makes it easier to read. And it keeps the version control free of dueling developers checking in bunches of formatting changes along with the interesting code changes. Of course, they get changed back when the other guy makes changes in there. (You could fix this if the "diff" tools, whether supplied with the version control or not, were smart enough to ignore superficial formatting changes but I can't imagine how the display would effectively show real changes in the midst of the formatting changes it was ignoring. Fortunately there are people smarter than me to figure that out.)
Added a little about questionable or confusing coding practices like using a variable for two or three things or over-factoring or doing things in a complex and possibly "faster" manner when you don't know that the simple way is too slow. You know the drill. Suggested the use of good sense.
Then I got down to the part about naming conventions, etc. Stuff like using English verbs and nouns in the right places in the names. Avoiding abbreviations and shortened forms of words, mostly. Comment as much as necessary and as little as possible because the code explains itself. (Oh, and, you have to make the code do that, too.) Keep the blocks of code small enough to mostly see on a single screen. Trying to imagine yourself reading the code in two or three years (or heavily sedated) and being able to understand it. (There are tools that can do this for specific languages but they take time to get set up so they yield interesting reports and I haven't figured out whether its worth the time or not. Flagging something as needing a fix when it really doesn't is such a pain.)
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
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/
What's all the fuss about? We use astyle (Artistic Style) to deal with this issue. Does the trick for C, C++, C# and Java.
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)."
We're talking about HTML and CSS right?
If you're doing it with other people, there *FUCKING HAS* to be a format standard that everyone understands. It's not important, so much, that they agree with it.
You show me more than one person working on something with no standard, and I'll show you a (in a few years probably) a codebase that's so fuct, that all troubleshooting is done by that company's hardware dept. If they have no hardware dept, they soon will. Of course I call it a hardware dept, but it'll really be an underpaid IT dept.
To anyone that operates a business with no format, I hate you.
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
Coding standards do make big codebases more readable. The funny thing is that they're so, so different everywhere. I just finished a gig with a team that liked to put opening braces on the end of the previous line; I hadn't seen that in years, and while I don't especially like it, it didn't take long to adapt to. I worked alongside an Art & Logic contractor team once, A&L has the most detailed and unique standard I've ever seen; I was complimented for following it.
The biggest problem is code reviews: a detailed standard makes lots of opportunities for twits who want to tie work up for days because they don't like the punctuation in the comments (yes, I've seen this.) I recall a junior guy-with-big-reputation who liked to bad mouth others to management for not meeting his standards (which were not always official, but once anyone was on a review it was blocked until they were happy.)
My answer, which I've never quite had the horsepower to try (I don't like being a lead, let alone a dev manager), is that code reviews are purely informational: they are still required, but once they are done and feedback returned, a coder is 100% free to check in. Reviewers document their opinions and coders had better document why when they reject reviewer feedback, but the reviewer is no longer an absolute gate for work they didn't do. Coders are required to solicit feedback(s), but remain responsible for what they check in; reviewers are not responsible for problems they document.
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
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.
What does it say about you that after so many code reviews you still haven't figured out how to write code that will pass review? You know someone will nitpick your code and you know they'll make you conform to the coding standard in the end anyway, so just follow the standard from the beginning and save everybody the time in the code review.
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
> We live in the future, why don't our tools enforce these standards automagically?"
Here we use a Visual Studio plugin that handles all the nitpicky coding standards for us. We're free to focus on more important issues in code review.
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?
Wrote a program that formated code to a defined standard, all the whitespace, endlines, and braces.... didn't change varable names though.... only took me an hour or so. Then I wrote all my code the way I liked, ( very few spaces, less keystrokes ) and ran ./autoformat code.c
Worked like a charm
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.
code designated for silly humans can have any coding standard they want. TOTAL ANARCHY.
HOWEVER
I work in the industry where my code is used in life critical avionics software. If we do not follow our coding standards, the FAA
gets antsi... do these people really know what they are doing? Showing a lack of discipline in design and implementation just points to
a POSSIBLE lack of consideration of all possible software problems.
Code that i write is generally read by me, and as such I'd like to see it in a way that is most comfortable and natural for me. In the event that someone else takes it over, they can feel free to format it in whatever way they want. I personally don't understand why anyone would prefer to use spaces over tabs and never will. Forcing people to use language constructs that are unnatural and unappealing to them are inefficiant and generally a waste of time and are generally unnecessary.
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
Algorithms should be covered in the design review if not specified in the requirements and not the code review.
It is very doubtful there is any hard evidence that code reviews are useful because they are such a waste. Lint does a better job as do compilers outputting all warnings.
Having worked professionally in the field for 8 years or so, I can say that style standards are only as good as they are small. If you have very few rules, largely in place to prevent "style wars" (as mentioned above), it is usually easy for people to agree on it and they tend not to spend too much time thinking about it.
I have worked in places where the interest was more on defining best practices across a team of roughly 10 people (the other 50 on the extended team could do whatever they wanted since we were rarely in each others' code). This was expected to evolve as people tried new things, brought external knowledge to the company, or learned from the causes of bugs (*shock*).
Let me be clear: almost none of these ideas were "style"! The vast majority of them were simple code-level ideas like "always initialize variables" with a "see bug #X for a reason why" reference on it such that it was obvious why you were doing this and any disputes were considered in light of preexisting hard data. This allowed an evolution toward correctness with only a superficial nod to style.
I have worked in other places where the style guide would actively make you write brittle code and even the reviewer would say something like "I agree with you that it is a inferior but that is how we do it here so you better change it" and it was so big and applied to such a large group that it had degraded into a religion (with its own "priesthood" to enforce the law). It became such a focus of code reviews that correctness was only accomplished by accident.
These days, I am sure that there is some balance but I am more likely to err on the side of few style rules (or none at all), as opposed to more. After all, if your developers are thinking about what the code look likes instead of what it does or how it works, your team has failed before it started.
I've been through the format wars, and they're mostly (but not entirely) a waste of breath. They matter only when someone is so egocentric or incompetent that they probably shouldn't be coding anyway.
Other kinds of coding standards do improve code safety, correctness, and maintainability. I mean things like MISRA, the "C++ Coding Standards" book (ISBN 0321113586) and their kin. Standards like those block many of the blatantly unsafe practices that lead to buffer overflows, undo the short-circuit semantics of && or ||, and cause other kinds of code chaos.
Two parts to the question and answer: 1) Development processes must be efficient, otherwise they'll end-up being ineffective. What I would do is have a criteria that must be met before entering the code review process... and things likes code-style must meet the entry criteria before the code review starts, so that the code review can be focused on higher risk type changes that have been introduced. As part of that overall process, the the "low risk" criteria will be checked by "some tools, or some person" and rejected " -- do discussion -- time if $$, the submitted has not met the minimum criteria. For the team to become efficient, these "low risk" criteria must become bread-n-butter for the team. Otherwise, trivial "low-risk", "low-impact" behaviors will dominate the teams time. Publish in a very public place statistics on the process. When executives walk by and see $$ being spent because some folks just don't want to agree to disagree and move forward -- it will be somewhat embarrassing, no? 2) Coding standards improve the overall efficiency of everyone that comes in contact with the code. It' is important for team efficiency. Inconsistent code style "may" not impact product quality, but it definitely can impact the team. If your company is a an OEM relationship or engaged with consultants that have access to code thru source license or SDK, all of the folks downstream will be impacted by the inconsistencies. Naming is huge, especially for tools that are developed to parse the code for a number of purposes.
you lost 100s of hours cause you were too much of a prima dona to follow the guidelines
It's about consistency which makes interpreting the code much faster. How code is written is never the point aside from it being bad good or sufficient. The intent of the code is what matters because - bugs.
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
Ever tried it before?
One of the few things it can do is enforce something like coding standards, so that you don't have people applying their own preferences to the "standard" when verifying your code. Instead they can focus on checking your rationale rather than the number of spaces behind line 309...
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/
That's what they all say
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."
All those NASA documents with NASA - National Aeronautics and Space Administration defined in the table.. when the acronym appears only once, on the cover, with the meaning spelled out. Yep, good thing the editors caught it when we left it out.
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.
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
It seems, though, that he could just use type checking instead of Hungarian notation.
The primary problem he's trying to solve in his examples is separation of code and data. HTML is code, whereas data received via the web is, obviously, data. You never execute data, and so to output a text string as HTML is always incorrect.
typedef char html;
So just make your function that reads CGI data return char, and make your function that writes HTML data only accept your 'html' data type. This way you don't even have to rely on people noticing the mistake because, if someone does it wrong, the compiler will bitch and moan about it.
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.
How can one "waste" time checking for whitespaces or tabs?
How can one "waste" time making sure .java files do NOT contain a single non-ASCII char?
We've got very strict guidelines but we do not waste time manually eyeball searching to see if people are breaking the rules or not. We're using scripts and commit hooks etc. that do enforce them automatically.
One example: we force every single file committed to our projects to only contain a subset of ASCII in their filenames (no spaces, no backslash, etc.).
We do a *lot* of stuff like this. And it's all both documented and automated. For the retards who wants to argue that tabs are better than whitespaces we point them to the specs and recommandations made by Google for the Go language. gofmt FTW! (and, no, we're no a Go shop)
Everytime I read about build scripts or whatever scripts / tools / OS issues / encoding issues due to "creative" names for filenames I can help but think the company I work for laughs all the way to the bank ; )
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.
It runs at the developer level on save and as part of the CI build. I'm look forward to not having to spend much time in code reviews talking about formatting
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
Kill it with fire! The tab character sux!!!!
And Python is super-lame for white-space being significant. FAIL!!!
Happy Mayan Apocalypse, everyone!
What is this "code review" you speak of?
giggity
... I have 2 rules for my team:
1) if you are modifying a file/component/module/... then you MUST follow the style of the code you are modifying
2) If I don't understand your code, then this is YOUR problem, not mine
Worked really well so far.
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.
Programming involves reading a lot of code. You basically read code 8 hours a day. So your brain needs to perform a lot of pattern recogition. It helps probably most people if the code has a consistent style across a language. Because it helps recognition. (Mind the "re" syllable in the word recognition. It basically means seeing something *again*). I am one of these people that get severely distracted by code that falls out of the common formatting rules. It is simply harder to read. It's easy to misread such code (think of boolean/arithmetic expressions, control flow, block structure). There apparently are people that are less sensitive to messy coding standards. But all of them that I know are bad programmers too.
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
PHP's original problem was that generating HTML is actually not all that hard. You didn't need all of those fancy real-language features; that would just create a barrier to entry!
"Well, apparently it's a little harder than we thought, so we'll add some things to the language and then it will be okay!"
The recent phenomenon of using Javascript on the server is the exact same pattern.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
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.
I worked at one place where the coding standard was a pre-comit hook on our version control. Before you checked in, it got formatted to match the standard, so diffs were at a minimum. Don't like that standard? Use a hook on checkout to format it the way you want.
It was great, because it killed holy wars. You like spaces? Use spaces. You like your braces like this {
}, fine.
It doesn't handle everything, but it got some of the benefits, without the arguments about what the one, true standard was.
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.
We live in the future, why don't our tools enforce these standards automagically?
If your tools don't do this, they suck. Get better tools.
For instance in Vim you can set the indentation and tab options for C and make the editor indent everything automagically. Likewise in Emacs.
Of course in some shitty IDE it's impossible to do this, and thus people spend countless hours moving whitespace around in a tool which is supposed to increase productivity.
And we have the rules for readability. So that there's one less burden for understanding. Code is complex as is, without having to understand Harry the Wonder Hacker's peculiar whitespace and indentation excercises.
... 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 work in a place where coding standards are rigidly enforced. And we work with a large data warehouse, where they have managed to name any given data element differently in pretty much every single table in which it appears. Do we really need to name the column which contains the zip code zip_cd, to save two characters, not when storing it (as in the reason for the y2k crisis), but when typing it in; sometimes, that is, when we're not naming that column zp_cd or just zip, or sometimes even zip_code? But damn it all, we're going to make up for that by naming the datasets in our programs uniformly: data1, data2, data3, etc; or merge1, merge2, merge3, etc. Because that is certainly better than naming them something terribly confusing, like "members_with_no_dependents" or "purchases_by_members_with_no_dependents".
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.