Slashdot Mirror
Does Coding Style Matter?
theodp writes "Over at Smashing Magazine, Nicholas C. Zakas makes the case for Why Coding Style Matters. 'Coding style guides are an important part of writing code as a professional,' Zakas concludes. 'Whether you're writing JavaScript or CSS or any other language, deciding how your code should look is an important part of overall code quality. If you don't already have a style guide for your team or project, it's worth the time to start one.' So, how are coding style guidelines working (or not) in your world?"
At my workplace, we just all plug the same code style settings into our IDEs, and everyone's code gets formatted the same way automatically. And yes, it matters: having everyone's code formatted the same way makes it much easier to read.
Of course coding style fucking matters. Code's generally going to be part of a much larger product that existed long before you joined a company and will continue to exist long after. You don't want the codebase turned into some sort of elaborate puzzle with 200 different methods of laying out code contained within. Uniformity makes maintenance much easier.
Betteridge's law of headlines says "No" ... Unfortunately, he is wrong this time! ;-P
- AC
I've always preferred to use tabs over spaces for indentation, 2 breaks in between major sections or functions, and clearly named vars or functions. The kind of code most people can drop into and say "Oh, I see where this is going" and immediately begin to understand and therefore modify.
I can't stand opening up any type of code, even web pages, and finding ugly difficult-to-follow lines which seemingly make no sense. Then again, it's all a matter of preference and perspective, isn't it?
What else can happen when an unstoppable force collides with an immovable object?
Oppan Allman Style
The thing I dislike most about discussions of coding style is that since the topic of coding style has an extremely low barrier of entry, everyone has an opinion. I know bad code when I see it, I could give a fuck how many spaces are in a tab or how many characters to a line.
Learn one word: consistency.
Be consistent from one piece of code to the next, from one project to the next. Be consistent about your design ideas, be consistent in your thinking. It's going to help you and anybody else working on the same stuff.
Everything else is sugar.
You can't handle the truth.
I do not see any point in coding styles whatsoever. All they do is slow down coding for all but the two guys that actually like the coding style as defined; for the rest it's needless busy-work to comply.
I agree that one persons code should look consistent; so someone should pick a style and stick with it. Also if I am making a SMALL change in someone else's code, I try to mimick the style of code around it.
It's so easy to run a code formatter on something now that someone else can read code however they like if it's really important. But while code is underway conformance to a specific style is not helpful.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
clearly readable code is the first step toward getting it accepted.
Get a program to refactor the code into whatever style you want. I'm amazed people still have make this an issue.
Let the company use a code formatter on the final code. Or just code in assembler, only one way with it.
Mine is best, yours sucks to the extent that it isn't mine and most editor/IDE authors are too lazy to make mediating style a critical feature; but they seem to be slowly getting there. Now get those goddam spaces out of my indents so I don't have to get carpal tunnel, or else make me an editor smart enough to automaticly import them as tabs and export them as spaces so that we can just. stop. talking. about it.
There are no shortage of automated systems perfectically capable of (re)formatting code. For this reason personal choices with regards to tabstops, bracing, spacing and general layout simply does not matter.
As far as non-decorative conventions and comments..consistency obviously generally helpful.
I do believe there is diminishing returns on overdoing it with added danger of folks not being able to function effectivly in environments where code is produced by other groups outside your administrative control using different conventions.
In short try to be consistent but never make a decision which presums either yourself or others have been consistent.
Ctrl+K, Ctrl+F
Presto, you've got your coding style for code that you didn't write.
Does chewing food with your mouth closed matter?
It totally depends on your audience. Is this code something that must be read by one person or a hundred? If its one other person, it probably doesn't matter unless they have strong feelings. If its 100 people then you should have a standard template so people don't waste time arguing. Personally, I know that my code will be read during a code review of about 5 people. I need to make sure that all of those 5 people are comfortable reading it. For example, I happen to be working in C# and some of my co-workers hate the var type declaration, so I don't use it. Some of them have strong feelings about always using braces, so I do. At the end of the day, as long as your code is easily understandable the minutia of style guides are just to keep other people from getting their knickers in a twist. That can be far more important than whatever code you are working on.
Dont invent your own style guide, use one from a book. Like Clean Code.
This prevents discussion and new team members might already know the rules when they join in.
Little differences -- like whether you put your bracket on a separate line from your condition, or how many blank lines you put in -- are not really important. What's the most important is that, when you modify existing code, you match the style of that code. Nothing's worse than a block of code that follows a different style than the code around it.
I've worked at a company that had a product that was open source (GPL & LGPL). We licensed the source code to other companies under non-GPL terms. One of the things that made our large project useful to them was the consistent coding style we used throughout. None of us loved the style, but it wasn't terrible and having 20+ developers all write the code the same way with the same conventions made it much easier for us to work together and with our OEM customers.
This is the first headline question I've seen that should probably be answered with yes.
Though the rest of the law applies, in that it is a completely useless question.
Next week's headline: "Do code comments matter?"
Python Reference Manual: 2.1.8 Indentation: Leading whitespace (spaces and tabs) at the beginning of a logical line is used to compute the indentation level of the line, which in turn is used to determine the grouping of statements. First, tabs are replaced (from left to right) by one to eight spaces such that the total number of characters up to and including the replacement is a multiple of eight (this is intended to be the same rule as used by Unix). The total number of spaces preceding the first non-blank character then determines the line's indentation. Indentation cannot be split over multiple physical lines using backslashes; the whitespace up to the first backslash determines the indentation.
Yes it matters. And one should not have one coding style, but follow each language naming conventions. Java, with its firm naming conventions and no legacy issues, is the far most readable code in real life, because most of the devs are told to follow the naming conventions early on. C#, on the other hand, is made to be just as readable, but due to large number of C/C++ devs coding in it, it is usually a mess, overflowing with underscores and other convention breaking stuff useless in the object oriented world.
As always, convention over configuration. Readable code is usually a good code. Can't stress this enough.. there is nothing worse, than having a team member, coding only in "his" style.
In my opinion, it depends. For a single person coding and making some program (doesn't even have to be in a company) and not planning on putting on sourceforge or something, it probably doesn't matter. In a company where code is shared and debugged between lots of people, yes it does. So all in all, formatting probably does matter in the long run.
This isn't the sort of thing anyone really disagrees with. It is more of a learning article, or a "I have expertise in this field and here is proof" article, than anything really worth discussing on its own merits. Even the inevitable tabs vs spaces, same line vs next line bracket discussions have little merit: In a large organization/community - its best to stick to published guidelines for a given language.
I don't really care how you *format* your code. Do you put the brackets on the same line as the beginning statement? Do you put a space between the function name and parentheses? Do you double-space your code? I don't give a fuck. That's all syntax. It's easy to figure out.
Coding style is more important to me, how the actual *code* works. Do you initialize your variables as soon as possible? Do you properly use for loops and while loops? If you use recursion, does it make sense? Do you give your variables meaningful names like $activityType, or useless ones like $_a? How do you decide when to break something out into a function?
I work on a project with several other people. We all have our unique styles, both for format and for code. I, for instance, have been told I code with a "LISP accent", rarely storing the return values of a function in a variable, rather using the return value as an argument to another function. Another puts a blank line between nearly any two statements. Another assiduously follows some code formatting standard nobody else in the company has read.
Although it can make it harder to work on each other's code, it has one benefit - you can easily tell who wrote the code. "Putting the braces on a new line? This must be Pete's code!" or "There's an underscore at the front of every variable name? This must be Jimmy's code!" or "There's a for loop that starts ''for (;;){''? This must be Kevin's code!".
And if I do go in to "someone else's code" and change or fix things, I follow their style, more or less. Unless I'm completely rewriting a section, or making enough of a change that it should be considered a rewrite.
When working with code written by more than one person you need rules. It helps with code review and helps new people intergrate into the project more easily. The larger the program and the more people involved the more stringent they have to be.
Of course many of the rules can be applied by the IDE/editor or post processed this is fine as long as submitted code is up to speck. It's genrally better to do it right from the beginning though.
The precise rules themselves don't make much diffrence as long as they are sensible. Consitency is key.
Most Damage is done by people who are AWAKE
1. Use spaces instead of tabs.
2. Make your code readable by humans.
Consistency is nice, but comments are way better. I could care less if someone uses spaces or tabs between shit, as long as it has comments about what the code is doing or trying to do, I'm happy. Well, was happy, I don't really code anymore.
Be seeing you...
The best article that I've ever read on coding style is Style is Substance by Ken Arnold.
I won't repeat what he has to say here, because he explains it better than I could. But I wish that more programming languages would follow what he is advocating, because we waste way too much time arguing about braces and tabs.
Nice to be reminded of these ideas. While they come up most prominently in our early years as software developers, we tend after a decade or two either to take them for granted (should we be so fortunate as to work in a place where everyone writes clean code as a matter of course) or perhaps to give up on them in despair (when working in a code maintenance regime that puts a priority on generating minimal diffs where the code base is - and must perpetually remain - an ugly steaming mess.)
The practice of software development entails in the same undertaking aspects of style, design, engineering, and science. On that spectrum, the stylistic element can seem relatively trivial, subsumed into the others. Okay, fine. What that really means is that when we encounter stylistic failings and inconsistencies, we're bound to wonder what else is wrong with the code. Style, in other words, communicates something about care and attention in general.
As a form of communication, it's interesting to consider the Japanese tea ceremony. Few human activities are so completely formalized. Its essential form is pure simplicity, where every action in every detail of movement can be given full attention. Every tea practitioner knows this form intimately. What's interesting is that this form, while aesthetically pleasing, is seldom followed exactly. It functions sort of like a carrier wave. How a tea practitioner departs from form encodes the signal, superimposed on the carrier. In feudal days, the encoded aspect was critical. It provided a way for people to communicate on subjects that were politically dangerous.
In writing software, we're probably not concerning ourselves with political intrigue. But still, how we express an idea in code provides important information. Consistency of form is reassuring, whereas departures from form draw our attention. We're bound to ask "why did he do it this way over here but this other way over there?" In good code, the reason should be evident. We should feel a small kick of satisfaction that we're inside the mind of the programmer, that we're on the same groove.
It's the kind of code we should all aspire to write. Style is not mere decorative flourish. If it is, something is wrong, because form follows function, and this would be form without function.
Parity: What to do when the weekend comes.
You stupid lazy idiot !! Yes, you !!
Just use Artistic Style for C and its derivatives C++, C#, and Java. I usually set it for "--style=ansi", but that's a project preference. External code is run through Artistic Style before use. This way, everyone knows the indentation is consistent.
For Python, of course, there are few formatting options, so this isn't an issue. Dreamweaver will indent HTML. Javascript remains a problem.
Almost all the posted comments are talking about formatting (tabs vs spaces, indentation, line breaks, etc).
While its good to be consistent with these. Style is so much more.
Consistant naming schemes for variables/functions/classes/methods etc.
Useful and meaningful comments.
Handling non-expected input and states gracefully
Catching and handling of exceptions
meaningful feedback to the user if there is a problem.
I would call all these things and more "style." These are the things that make it easy to maintain code after it is written. They also help to reduce the incidence of bugs.
In my experience, "messy code" is a good indicator of "messy development". I strongly believe that the structure and appearance of the code is a insight into the developer's brain. And messy code: Usually means trouble ahead.
And yes: IDEs can help with automatically formatting code: It's good since it allows developers to spot obvious mistakes, and it's bad because it allows bad developers to hide structural errors. But probably good overall.
There's more to coding style than simply indentation: The really most important concept is clarity.
If a developer cannot explain (in one sentence) what a given function does, what a given class does or what a application does: be worried. If the developers thinks they know and still cannot explain: Be very worried.
There are best practices and rules a programmer should follow and those should be set at the team level...call that "style" if you want. But formatting? Who cares? The IDE takes care of that. If the diff engine on your IDE or repository can't tell the difference between code changes and whitespace changes then something's wrong. I was on a (Java) project where half the team liked braces on a new line and half didn't. When I worked on code written by someone else, the first thing I'd do is hit alt-shift-F (Netbeans) to reformat the code. I'd do the same if I pasted some code...reformat the file to get the new code formatted the right way.
Our SVN repository wasn't glutted with meaningless diffs and I didn't face hundreds of conflicts when updating code. In this modern age (despite the lack of flying cars) it's silly to have to conform to one standard to make the software happy. Software works for us, not the other way around. I use software to format code the way I'm most comfortable with...why should everyone compromise so no one is happy? Just set up your tools properly and stop worrying about formatting.
COBOL is a good example - it forces you to indent properly with A and B columns!
My does:
My don'ts list is getting shorter and shorter. Most programmers have reasons why they produce the code the way they do. Lack of experience should be met with understanding and appreciation for improvements.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
I promise if your team is kicking around coding style conventions you might not be doing important work. Be careful. This might be a clue you're replaceable. If your doing creative work nobody asks about coding style. They only ask, is it new, cool, and ready to ship. Respectfully, Jim
When writing code everything matters.
Forcing people to follow a style I think is counter productive. It prevents the styles from evolving. In recent years for example people have been moving towards using better naming rather than commenting.
Strict rules prevent creativity and for that reason I disagree with the conclusions of the article to require one. Requiring anything more than just to follow a style no matter what that style may be and to try to maintain the existing code in the style that it was in is about as much as you can do.
"The best way to predict the future is to invent it." - Alan Kay
...get your ass on the unemployment line because that's where you belong! It's simply part of being a professional. You think chefs that constantly have sloppy as hell workstations keep their jobs? Even if they cook really well at some point they tend to if not be unemployed than certainly be less well-regarded than their otherwise would be. Same thing is true of a sloppy coder.
Note that I'm not saying *WHAT* style is important...I personally prefer spaces over tabs and braces at the end of a line but other people feel just the opposite. Neither of these options is important. What *IS* important is that there is a well-defined and well-known style guideline and that all developers on a given team adhere to it, whatever the actual rules are, whether they like the rules or not (although I *AM* a big fan of having everyone contribute to the rules and re-evaluate them as time goes on... no point having developers that feel like they have to follow some stupid, rigid rules they hate if it's at all possible to avoid that, and just having everyone have a say in the rules goes a long way to ensuring that's the case).
Someone else pointed it out, but consistency is the key concept here. I can't tell you how frustrating it is as a project lead to have to review code from five different developers who ALL use a slightly different style, or, worse still, where each developer DOESN'T EVEN FOLLOW THEIR OWN RULES ALL THE TIME!! I've been becoming more and more anal about this sort of stuff as I've moved up the ranks because I've witnessed first-hand the detriment to maintainability such a seemingly innocuous thing like how you format your code can be.
But, the bottom line is it really CAN be a big deal. If for no other reason than a fix we should be able to turn around for a client in two hours takes four because they have to parse some ridiculous-looking code... and yeah, it definitely CAN get in the way of understanding. Of course, this assumes that rules around commenting are part of your style guidelines, which they very much are on my teams now.
And don't give me the "let the IDE do it" line... that shows a core problem in you. Writing good, clean code, format-wise *AND* content-wise should be a deep-seeded need in you, something you do automatically whether you have the tools or not. Too many developers I've seen over the years skate by because they have tools that cover their shortcomings... but the shortcomings are still very much there and they are just flat-out not as good of a developer as the people that have attention to detail and logical thought and a desire to make everything neat and clean embedded in them at a deep level. You can almost without fail tell who's been programming since they were young and who started with programming as a passion versus those that went to school for it and/or came to it late in life. They may *TECHNICALLY* be decent enough programmers, but there's always something missing, something very valuable, something that makes them not as good as others... and how you format code has proven to be a *VERY* good indicator of this in my experience.
So yeah, it's important, quite important actually. And if you don't think so, enjoy whatever job you can get, but I promise you, *I* won't be hiring you.
then you have never worked on a free software collaborative project; you have never submitted patches to free software projects; you have never worked for a large software engineering firm with ISO9001 (Software TickIT) practices in place;
I have worked with large engineering firms; I have not have submitted small patches to OS projects long ago but as I noted, for small changes I mimic existing coding style.
I have worked with dozens of teams ranging in size from two to thirty or so.
in fact you have probably never worked with revision control tools ever in your life.
I have worked with many such tools starting with RCS, then CVS, then git.
running a code formatter and then creating a patch automatically includes your modifications in amongst a bunch of whitespace modifications,
You may have not noticed where I said small changes I mimic existing coding style. I am talking about new code, where someone who is submitting the code is also the guy who has been writing it for a while. As long as the people working on that block of code are consistent, there is no SCM issue with them coding as they like. I am not saying to re-format a whole file and check that in; just to make it more readable as needed.
bottom line is: i'm not impressed.
And I am sad you cannot read, nor understand the point I am making.
Hopefully for the good of future teams you can eventually lodge the stick out of your ass that companies have made you push in so far you don't even know you have it any longer.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I'm a stickler for consistent styling as well as formatting. It's one of the reasons I like .Net so much - they have a nice code analysis engine built into their build system as well as a decent style engine that can be added on. There's a bit of adjustment when the source control system rejects non-compliant code, but once you start learning what the guidelines are, it gets easier to write it properly the first time. The base framework itself is reasonly conformant to those guidelines, so more effort can be placed towards effectively interfacing with the libraries.
And it's interesting that almost every place I have worked *wants* to use MS formatting/style guidelines; it's just rare for the boss actually pulls the trigger on enforcing it (inevitably, the argument goes towards "yeah, but how much of an effort will it be to make all of our existing code conform?"). Fortunately, I am currently on a .0 product version that entails a rewrite, the question of making existing code compliant is a non-starter.
Format your code so that the coders can read it.
If your'e on your own, format how you like.
If you're on someone else's project, format how they like.
The compiler truly does not give a rat's behind about it, so approach it as a people issue.
And that means being prepared to capitulate if someone else in charge wants things done their way.
The compiler doesn't care how you format the code.
Your boss, however, might.
There just haven't been any significant improvements to the K&R coding style. Just follow it exactly.
The best part of K&R is it appreciates the importance of vertical space. Don't waste vertical space with stupid conventions like "standalone braces" or placing every HTML attribute on a separate line. When vertical spacing is abused, then other programmers can't see a particular line of code in context. To display context you need to display as many lines of code within a limited space, while still having space available to break code segments into related groups. Otherwise, you force other programmers into having to endlessly scroll backwards and forwards to "see the forest for the tree".
<GrammarNazi>It's "deep-seated".</> I understand why "deep-seeded" may seem reasonable; but it's wrong.
When I think of coding style I think of the following: Methods shall not be over 40 lines long. Files may not over 1000 lines long. If blocks must not be nested more than twice in same method. Do not use the else command. Do not use Ternary operator "?:" Do not nest loops more than twice in the same method.
And Plan 9 style is the only acceptable style.
...if the coding style is built into the language itself. See: Python :)
Yes, next question?
-- This space for lease, low setup fee, inquire within!
Or perhaps he really meant deep-seeded since the words describe something.
This is also a forum, and you wasted moments of your life trying to correct someone on something other than improper spelling and grammar. You've corrected their meanings....
-- This space for lease, low setup fee, inquire within!
it does
That "anal retentive asshole" is making everyone's job easier - including yours.
I have never found the anal-rentiive to make anything easier overall.
Because human minds see patterns, and they decipher familiar patterns quicker and more accurately.
Exactly why letting people code as they wish is not a problem, as long as each coder is consistent. When you open any given module, it's all consistent and your brain latches on to the patterns in use quickly.
So when everybody's code looks the same, it's much easier for other coders to maintain
I'm confused: Does the human mind see patterns or not?
Of course, you probably didn't bother to think about that, now did you?
Far more than you will ever know.
Letting people code in a style closer to what they prefer reduces errors going in. Perhaps you love finding errors later; I do not. I'd rather they never go in. But perhaps you did not think about that... now did you?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
More important than using your own code style is using the language code style if there is one. For example in C# you should code in the same style as the .NET, in Java like the Java SDK and in Objective-C (on OS X/iOS) like the Cocoa APIs. Don't invent your own style if there is already one existing.
When someone other than you controls what code gets published, you buckle down and do what the fuck he tells you.
And that includes kowtowing to their preferences on coding style.
So if you're coding on someone else's turf, do what the fuck you are told.
And by idiots, I mean the generic morons that colleges spit out every year left, right and center.
For those who are smart, even spaghetti GOTO'd to hell code can be easy to read, if a little annoying.
However, ideally there should be at least some sense of common style.
The simplest way I can think of it is this: describe your basic layout to a child in your head.
Write it down. Does it sound right? Could it be better? Is the kid annoying you yet? Did you tell him to sit on the naughty step or did you listen to him?
Are your coworkers looking at you funny for talking to your trashcan? You finished yet?
Main first-run code at top. All the stuff needed for a successful use of a project, such as entering a number in a spreadsheet, saving, closing.
Order these in what you'd consider the default / popular use-cases of that code by the program and user.
Sequence diagram is the most important in this. USE it for order. Sequence Diagram is the most important next to actually testing the thing to make sure it works.
But if you done a good and thorough enough sequence diagram, these problems tend to evaporate.
Make everyone analyse why they did the code that way. If they can't explain it to child-self, it is likely poor already.
Write sectioned code.
After that, syntax, personal bracing style, none of it matters.
All that matters is code that is legible and doesn't require the persons brain to actually interpret the damn thing.
That variable Count could mean anything, Count what?! Explain your secrets variable! TALK!
Putting stupid restrictions on freedom of style just inhibits development.
You just need people to explain things clearly in a basic line and the actual code itself and everything is peachy.
If that fails? The people you are working with are not developers. Period. They are workers.
Arguing over coding style just seems to be part of the software development mentality. It was going on 30 years ago when I first started in computers, and it will no doubt outlive me easily. In management, when you are looking for something to do, you call a meeting. In software development, idle time can always be easily eaten up by starting a discussion/debate/argument over where to put the lousy curly brace or parenthesis.
Yes, yes, coding styles are more than just indentation and such, but in the end it has always seemed to me to be about a few things:
1) Is the code readable?
2) Is the code consistent?
3) If the code is not how I would have written it, are items #1 and #2 above being observed?
If a piece of code passes all three tests, then I suggest that there is nothing wrong with the coding style. This opinion may not be the latest rage on the software lecturing circuit...but it has proven to work just fine across 30 years of development, countless problem domains, and project teams ranging in size from 2 people to 500+ people.
I personally hate coding styles, a coding style gets in the way of producing code. If someone wants my code formatted in a certain way then they should format it when they get it. Almost all commercial IDE's and Text Editors can format code at the click of a button so if someone really wants my code formatted they should set up the rules and do it themselves, after all if the argument is they can't click a button then it's not my fault.
I came here expecting endless threads of coding style religious wars. I was not disappointed.
I like to wear a black Versace cocktail dress accessorized with fire engine red Prada fuck-me pumps when I code. It makes the occasion special.
Vertical space is very important. I agree that breaking submodules out with v-spacing is as important as using braces to collect a group of actions together. The braces tell the compiler that the group may be viewn as a single object. The spacing/vertical spacing of lines tell the coder that the segment is a disctinct sub-object or module inside a group of code items.
.
When you've got to be able to de-cipher and re-jigger someone elses code to get the job done, a stable and well-defined coding style means that the job really can get done in a finite amount of time.
Code formatting can be a religious issue (I have my favorite style) and just like this article says probably often stems back to trying to please some forgotten professor. Often there is a logic behind each style rule. But mostly I agree that there should be one true style at any given company. In a weird way it might be good to have a company style that would offend any fresh CS major in that they could be shown the style and told that style is not negotiable. This would show if they are a team player or not. A genuinely good programmer would know that after a week of programming the new style that they would be fine with it.
//Comment the crap out of everything. This comment crap also ends up with huge comment headers at the top of every page. The worst comment style is when people break up the parameters to a function onto separate lines; ah la C code from 1982.
But my main complaints about other people's styles is that they do often come from the small assignment to be marked school of needs combined with 50-60 year old professors who learned their stuff in the 80s. This results in rules like: no line longer than 80 characters.
Then there are the document hounds. This comes from the corporate school where managers need yards of documentation. So they insist upon strange comments that proceed every comment with the goal of generating huge documents that nobody will ever read and are probably wrong since they don't generate runtime errors if they get out of sync with the code. This is a case of mission creep where the programmers are also supposed to generate documentation to make the manager able to show he is worth something.
The key is that the style should come from the goal of creating a product quickly, that is bug free, and can be maintained with reasonable ease. Once rules creep in that don't concern these three reasons then they are stupid rules.
The one code rule I wish all coders would follow, even if they followed no other rule, is that of indentation. I've seen so many times code commented to denote that a certain curly brace was the end of this-or-that code block. What lame code that is! With proper indentation, no such comment is needed. In fact, with proper indentation, very few comments are needed, which is just how I like my code.
diFFERencE at all. If
THEre is A WAY yOu LIkE
tO wrITE theN jusT dO .TRUE proFESSionals CAN hanDLE it
it
SMOOThlY
Every freaking time I had to work under someone else style, I wind up writing code that has to be bug fixed or optimized somewhere along the line. Whenever I write code in my own style however I rarely have to revisit a function to fix bugs in it, not bragging just saying it's incredibly frustrating.
I don't want to paint pictures with text. I don't want to write code that makes auditing happy. I'm not trying to blend in with other coders. I write code that works in the most efficient way possible with as few bugs as possible. That is the only thing that matters to me. 90% of the bugs I have to fix in someone else code would never have happened if they just dropped their bullshit style and thought out all the edge cases ahead of time. An hour of planning for a function can save weeks of debugging if you stop trying to be an artist and start trying to be an engineer.
I wonder how long you have been writing code, if you don't yet realize that sometimes aligning things vertically across several lines can increase clarity. If everybody gets to set their own indentation amounts (by changing tab width), then this benefit is lost. Tables were invented for a reason, and sometimes code is tabular. And if you think a tab character is how you get a table, you are sadly mistaken.
For example, having same-line comments start at column 60 (when possible) makes code easier to read. If you go changing the tab character to 4 spaces, that alignment is ruined.
Also a reason for not using proportional fonts.
If you think the only way anybody will ever view your code is in a "sane IDE", you are mistaken. Just because your current IDE can compensate for your bad formatting, that doesn't make your bad formatting a good practice.
It's a standard, whether you like it, or know about it, or not.
Whatever style you choose, make sure that it can be generated with whatever automatic formatting tools you have available. This allows you to cut-n-paste code from other sources, and not waste precious time hand-formatting it (or leaving it in the wrong style). It also avoids the problem of lazy programmers feeling butt-hurt when somebody points out that their code does not follow the style. They can simply run their sloppy code through the pretty-printer before committing it.
Only on Slashdot would there be a debate about what constitutes a tab. Half the reason I love this site. Although, why not bring up when it's appropriate to add a space before or after a parenthetical. Using spaces or tabs, you're going to get basically the same result in your code. The real variance is in parentheticals and curly brackets. Those are all over the board.
This signature intentionally left blank.
Sounds like somebody lost his job to a better coder, but doesn't want to admit it.
There is a strong correlation between developers that cannot follow a style standard and divas.
That may be. I am not one of them.
I CAN follow other standards. I already said for example I do so when editing other people's code, right from the outset.
I also CAN follow other coding standards as teh job requires, and have done so a lot.
But what follows from that is experience, and in my decades of experience across multiple languages, coding for both client and server backends coding standards are in fact a total waste of time. That is what I am telling all of you. Yes lots of people can follow a coding standard, but it is wasteful to craft one and to spend the time trying to get coders to follow it.
Especially since there is a lot of grey area: like defining the common vocabulary (like the expected behaviour of getX, createX, findX, selectX, process, run, execute, ...)
What language is most of that gray for? I would also say definitions for how code should behave is actually more API conventions than "coding standards". It is more a design matter.
Free code style, in practice, would only mean that you are working most of the time with code in a different coding style.
Not at all. Read what I said again. Code you are writing from scratch you write how you like. Code from other people you try to keep the given style. So over time you spend only a little time coding in other styles, most of the time in a module that you have been working and and debugging. There might be some small negotiation if one or two other people are in the exact same code as you at the same time to not write something in a way they really dislike, but it doesn't need to be an edict from oh high to work out.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
That's what you don't understand - people can look back through history and realize that I consistently advocate a position, not that I'm some loser AC yanking chains like yourself. My posts are serious; AC posts on a topic like this are pretty much meaningless garbage because you can't tell anything about the level of experience the person posting has.
Hell, even my UID alone tells people I have 10000x more believability than yourself.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
What you have laid out is way better than the end result of most coding standards, where all of them would have been named "feature_37_count". You know it's true.
Also variants of naming are easily cleaned up later by refactoring tools if the situation gets to be as dire as you have presented. If there's a good reason to help make the code more consistent in that way one should do so; it's not the same as re-formatting a file...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
See style(9). Kernel code is expected to follow this format; whether the programmer likes it or not has no bearing. The same is not actively enforced for userland programs and their source, but is highly encouraged.
As an author of a 3rd-party FreeBSD program, I chose to follow this document as well, just to keep everything consistent.
Makefiles have similar requirements; see style.Makefile(5).
Yes, proper Coding styles are somewhat important. What I feel is even more important is to properly name variables, classes, functions, members and so on. I am German, my english is good enough to write this text, as you can see. But I am working on Code which has been developed by someone whose English skills are rather limited. But this guy thought it would be a good idea to use English names for the things listed above.
So for "Durchschnitt" (engl. Average) he used "Intersection". For "Werkstatt" (engl Auto Repair Shop) he used "Workstation".
I asked him why he did this and his answer was that he used an English-language framework (MFC) and it would "not be looking nice" to have German-language variable names and English-language methods (e.g. werkstaetten.GetCount()). Which is of course a big-time bullshit argument, as the most important thing with source code is the Ability To Understand The Intent Of The Programmer, and not "lyrical considerations".
So, I use German names, because
+ Programming is a highly complex intellectual activity
+ I can express myself best in my mother tongue
+ I want to reduce the possibilities for mistakes to a minimum
+ I give a rat's ass about aesthetics if that compromises the Communication Of Intent
The same is for documentation - don't use English "because it is cool and a sign of modern business". Use English if that is your mother tongue or if many of your essential team members can't properly read your mother tongue.
This advice also comes from Software Engineering "gurus" ( I can't recall a specific name right now), I am not the inventor of the "use your mother tongue in programming" maxime.
Certainly, whatever human language you use, try to
1.) use Proper names. Don't invent your own silly terminology if there already exist commonly accepted terms. Check with wikipedia.
2.) ask other people for feedback about your naming conventions.
3.) focus on the business side of variable names. "ulPrivCR" is not as relevant as "cashRetained". People can easily look up variable definitions and there is no need to encode the type into the variable name.
4.) Try to balance brevity with expressiveness and "ease of reading". It is not always easy, I admit. E.g. use "NumErrorsFiltered" insted of "NEF".
In an embedded project, you may have inherited several different styles in the kernel code, specific drivers, and special libraries. What I do is adopt the style that matches the context, especially when moding existing code. Sure, if you build a project completely from the ground up, you can strive for consistency. But face it, these days your going to pull in something that has been coded elsewhere. Just use good taste. If not, get a code beautifier.
..plus some discipline might do the trick: Just search for the method definition headers (something like \w+\:\:\w+) and then for a "{" in the next line and then just insert the logging code/macro. I know it will not work 100% of time, but it would save a ton of editing time.
I did something like this to get a makeshift mem leak detector (just look for new and delete) and it works reasonably. I found real leaks. But yeah, a kludge I have to use because MFC thinks they need to overload the new operator so I cannot do that.
A Computer Language Formatting Nazi. There are tons of reasons why code must be formatted in different ways and the "let's standardize" crowd with their two nerve cells can interbreed to produce more MBA "talent". They also love "standardizing". They want to think of software engineers as "standardized slaves" that can be "uniformly exploited".
I will in the meantime set up rules which I an everybody else can break when it makes sense in a specific situation. I don't need Nazis to hold the hands of programmers with two years of real experience.
Go fuck yourself Nazis and let great people design great stuff in their bedrooms. And no, I don't mean this ironically. Linux was conceived in a student's bedroom, not in the Corporate Nazi Space.
..and my code is as nasty as the words I will lob at you if I have an issue. NowGoFuckYourselfAndreformatthiscodeforme.
All your bean-counting might give your words a scientific appearance, but it does not at all address the real issue of software engineering. Neither do I think that bean-counting does address many other engineering issues.
If you cannot formulate problems with code in prosa language, you are intellectually retarded. Do you need to hide behind all your beans ?
Your "coding style" focuses on the irrelevant things and gets them wrong, too. With IDEs that can easily navigate code, the size of files becomes more or less irrelevant and there are many situations where you need methods longer than 40 lines. Apply common sense and review extremely long methods - sometimes they can indeed be shortened. But don't set up stupid rules "that must be obeyed".
If you don't have revision control, you can safely ignore all and any issues about code formatting, because you will have much, much bigger issues at hand than code readability. Quit That Company Today.
Code editors (at least most of them) are still stuck in a dark age where everything comes down to hand-crafted ASCII-art, which is complete and utter bullshit. Editors could and should work much closer, if not directly on, the AST of the language in question, and completely abstract away all those pesky details like indenting scopes or formatting comment blocks "properly". That stuff should be left to user preference and style sheets.
But I guess that would put an immediate end to the religious zeal displayed in tabs-vs-spaces (it's of course ts=8 sw=4 noexpandtab, noobs!), would not mask syntax errors in gobs of meticulously crafted gunk, and take all the "fun" out of programming.
Fight hunger. Filet a politician and send him to a 3rd world country of your choice.
For Java project a must. Agree on coding standards and then enforce/check them using Checkstyle.
Style guides force people to be sensible.
The thing is - no, no they do not. I've seen plenty of nearly unreadable code that complied (roughly) with local style guides.
If you've encountered rational looking C++ it's because they knew what the hell they were doing, not because the labored under some all-powerful style guide.
That's the trouble with coding standard guys, they claim coding standards work while all the while it is the people who can code clearly without them are the reason they think it is so.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
All I am hearing from everyone is philosophy and opinion, but in all of it there are kernels of truth. It is exactly like religion, there is no difference. With regards to what I use, the bulk of it centers around reducing the amount of time it takes to read a code block. If you can't read a code block in a couple seconds that you haven't seen for years then you're probably doing something wrong.
Non sequitur: Your facts are uncoordinated.
I've noticed that when people talk about "coding style", they often mean things like indentation and such.
For me "coding style" should be about things that really, truly matter in the grand scheme of things:
* Are the .cpp and .h files designed for reuse? Can you take the .h file and #include it somewhere else and have it JUST WORK GUARANTEED? If you link in the .cpp file into another program, do you have to add a bunch of unnecessary .o files to make it link?
* Does low-level code make calls into high-level code? For example, does the code that packs and unpacks serial protocol strings make direct calls into the UI to report if it encounters a protocol error?
* Does low-level code call printf directly for tracing? Did the writer of that code have any idea how that's going to work if you need the UI to collect and organize the tracing for 20 different subsystems and display it all in a special GUI window?
* Does the code use platform-specific features when it could just as easily have been written to use an equivalent portable feature?
You'd be amazed how many people obsess about exactly where to put the left curly bracket, but then you realize their code has no master organization plan, poor modularity, little provision for reuse of code, total ignorance of portability, poor definition of what a particular module is for, a poor concept of code groups and code hierarchy, poor division into service-providers and service-consumers, etc, etc.
yes it's better to have a consistent codingstyle, BUT what codingstyle is the bigger problem, as what is great to one person might look awfull to another, good codingstyle is all in the eye of the beholder. for instance, comments, one thinks let the code speak for itself, and others think comment on what you intend the code should do.. another example is lambda expressions, some swear by them and use them everywhere to the extreme, others use them only if it doesn't make the code harder to understand (since lambda expressions are 'just' functions/procedures with no name).. As I said, good codingstyle is all in the eye of the beholder, but a team should have at least one global codingstyle...
For 10 concurrent developers it will set you back about $10,000. BattleMap (now called McCabe IQ) will set you back about $30,000 a seat, and can generate test cases for unit tests which will test every branch path, and correlate them back to line items in your requirements documentation.
Probably overkill, if you are not working on a life support system of some kind, but the tools exist.
I love the Borland color scheme. I run that in my code editor. I wish I could find a good TrueType "VGA" font to make it even better.
doesn't that get in the way of preserving your job by becoming the only guy who can work on your code?
Coding style is important, but if formatting differences make a huge difference in readability, it's probably because the code is poorly designed. Code that has small functions, well-designed classes, well-partitioned modules, etc, is easier to understand even when the formatting is not all that great or consistent.
I'm one of those people who is obsessed with coding style, but I'm not in love with any one style (well, I have my personal style but it changes over time). The main reason I like a style is to "play well with others".
In my job, we have (relatively) brisk turnover as people are brought into the project and moved out. The team size has gone from 2 to 30 and down to 8. People come and people go, but someone has to maintain the code for 20+ years. Having everything consistent makes it easier to bring people in and to keep things flowing easily.
During code reviews (we have them for every check-in), I consider deviating from the coding standard with justification to be wrong. Yes, it is nit-picky that the formatting is off or there is a missing space after the "if" and before the "(", but the simple fact we're working on a codebase that will be maintained by dozens of people over decades. A little work now significantly reduces the effort to maintain it later.
Now, that isn't to say that some standards drive me nuts. We use "m_" in front of our local variables at my current job. I *hate* it, but it is better than nothing. I'd rather go through the regular change process to get consensus instead of abandoning it because of a personal reason. Likewise, I've submitted patches to Mono previous, though I find their coding standards to be... uncomfortable to work with.
In the end, I only care that a standard is in place, not the specifics of it.
Not in Go programming language.
Programmers are plagued with too many decisions:
What do I name it; how should I implement it; where do I put it? What should it look like?
I personally think the strongest advantage to adopting style/standards is to get everyone to shut up about the formatting and focus on the code.
The more I can get my developers (myself included) off of the 'gee should I do this?' bandwagon with clear-cut expectations/guidelines you can focus on the logic.
ClearlyAsLongAsTheCodeWorks,
and_someone_can_still_read_it...