Does Coding Style Matter? 479
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?"
It's easy with an IDE (Score:5, Insightful)
Re:It's easy with an IDE (Score:5, Informative)
... and it makes version control diffs shorter and to the point.
Re:It's easy with an IDE (Score:5, Insightful)
... and it makes version control diffs shorter and to the point.
...and makes global search and replace easier, because you can more often use plain strings, rather than having to construct a regex.
Re:It's easy with an IDE (Score:5, Funny)
Coding style has one function and one function only: To keep the Aspergers productive. For normally functioning people, any coding style is as good as any other (in other words anything that isn't a mess), but for Aspergers it is important it is consistant and strictly enforced, otherwise they will complain loudly and start arguing over which style is better (as evidence I present every thread in this story).
After enforcing strict coding style only one more thing is important to keep the Aspergers productive: Never mention or talk about coding style, and forbid anybody from ever bringing it up. If it is brought up, nothing will get done that day.
Re:It's easy with an IDE (Score:5, Insightful)
Sounds like pandering to the lowest-common denominator.
Why don't you switch to programming in VB while you're at it?
Bullshit. If I want to search for every time that a certain condition is evaluated, I should be able to search for "if (foo.bar ==", not "if\s*\(\s*foo\.bar\s*=="
Wait? Is that even right? Can = be used without escaping when it is outside of a capture or a positional assertion???
Re:It's easy with an IDE (Score:5, Insightful)
Re:It's easy with an IDE (Score:4, Insightful)
That's silly. You let the experts in your team write the "complicated C++ meta-template programming techniques" and the mediocre programmers use them. That's the point of C++-templating: Make it easy for the users of the code. It's incredible what kind of extremely convenient libraries can be written by template wizards.
Gladly the next standard will also make it easier to write, see "static_if" proposal.
Re: (Score:3)
Re: (Score:3)
You let the experts in your team write the "complicated C++ meta-template programming techniques"
No, No, and No again! What you are suggesting is nothing more than compartmentalising a team such that programmer A owns that bit of code, and programmer B owns that bit of code. It's nothing more than an artifical barrier for less experienced members of the team, designed to prevent them making small commits to address any bugs they may find. It makes it much harder to distribute the workload evenly between
Re:It's easy with an IDE (Score:5, Interesting)
Having a consistent style means that you don't end up in the situation we are, where we have several patches that are probably a days work to merge with the main line, not because our patches are large, but because some bonehead decided it would be good to run an automated code reformatter on his source tree.
This not only reformatted everything to a style that no-one else on the project uses, but re-sorted all the fields and methods in the source files affected. This made everyone elses copy of the source conflict violently with essentially every change made in the reformatted files, giving everyone else the headache of re-implementing their patches.
Peoples edits continue to make the format of these files a mess because they are indented in a way that's inconsistent with the source.
Alas, we can't undo these patches because the bonehead is the lead developer. But catering to prima-donnas means more work for everyone else.
Re:It's easy with an IDE (Score:4, Interesting)
It all comes down from the guy in charge. I've set the coding style at two of the last three companies I've worked for, and while new guys may not like it, it does promote effective teamwork. It's a lot more than just indentation. We use the same data structure styles, iterator styles, and everything from start to finish. It can be very difficult to determine who wrote any given piece of code, and a git-blame shows that it's a patchwork quilt with everyone contributing all over the place.
The guy who I will say is now the lead developer of our main software suite writes code that looks exactly like mine. We've even on occasion wrote entire functions, in the same place, which were identical down to the last character, even in the obligatory comment. No git conflict in that case. At the other company, there literally were no coding style guidelines, and the result is no one was able or willing to easily edit anyone else's code. That makes it very difficult to move people around to projects that need them most.
There are a ton of developers out there who are loners. It's a field that attracts geeks who are somewhat social-phobic. I've never seen programmers voluntarily adopt a common coding style. It's more fun to fiddle around on your own. So, instead of working together as a team to solve real problems rapidly, individual programmers go off in different directions, learning more about different ways to write code than actually writing code.
Re: (Score:3)
And btw, only idiot would use tabs instead of spaces, 3 spaces actually
Re: (Score:2)
Re: (Score:2)
JetBrains IDEs allow you to do that... I can't imagine that most don't have context rules for adding blank lines.
Re:It's easy with an IDE (Score:4, Insightful)
Re: (Score:3)
Eclipse can do it. You can setup a formatting style and then have it auto-format on save or do it manually with Ctrl+Shift+F.
Here's a screenshoft [imgur.com].
Re: (Score:3)
That's along the lines what I was thinking (but not exactly). A good IDE makes coding styles far less important than they use to be. I can load someone's horrendous looking K&R styled code, hit the "reformat" keyboard shortcut, and have readable code as a result.
Coding style only matters if you're not using a decent IDE.
Re:It's easy with an IDE (Score:4, Insightful)
.. and then you commit your changes and everyone wants to kill you. You just broke all their patches.
There have been various proposals for an IDE that stores the sources as a raw format that has no formatting, and you apply the formatting in the view, but they obviously have the disadvantage of not working with a plain text editor, needing a special IDE, probably a special version control system as well.
And it should never matter today! (Score:4, Insightful)
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.
Er (Score:3, Insightful)
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.
Re: (Score:2)
coding style fucking
- I am aware of different styles of fucking, but this new 'coding style fucking' intrigues me. So you are coding and she is .... trying to distract you from it with your 'fucking implement'? Or is it about maintaining proper indentation at every point of the fucking perimeter? Do expand on this theme.
Re: (Score:3)
You're stuck on the idea that coding style is just whitespace. There is not, and cannot be, a text format utility that unifies coding styles.
Moreover if you read the article, one thing a coding style could help to catch is a missed break in a switch statement. It would be wrong to automatically add a break (because it might be intended to fall through), or a fall through comment (it might be intended to break). That's a layer of defense that doesn't exist if you don't have all your code (or at least, all
Kinda Subjective but... (Score:5, Insightful)
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?
Re:Kinda Subjective but... (Score:5, Insightful)
Out of curiosity, why do you prefer tabs? Seems like unless everyone has the same tab size set, it can make the code more difficult to read than spaces.
Further, most IDEs and text editors have "smart tabs", allowing the simplicity of working with tabs even though you're using spaces.
Re:Kinda Subjective but... (Score:5, Insightful)
I use tabs because anyone can set the width to whatever they like (2, 4 or 8 spaces usually).
Re:Kinda Subjective but... (Score:4, Informative)
I use tabs because anyone can set the width to whatever they like (2, 4 or 8 spaces usually).
There still exists a lot of tools that assume tab stops are 8, without the ability to change them. Some people use those tools by choice, some people use those tools by mandate.
Re:Kinda Subjective but... (Score:4, Insightful)
And when you use tabs, it doesn't matter what tab size they assume. That is the point. Proper use of tabs means you use tabs to indent to the block level and spaces for further indentation, like so:
{
<-tab->a = long expression
<-tab->____continued;
}
Re: (Score:3)
And when you use tabs, it doesn't matter what tab size they assume. That is the point. Proper use of tabs means you use tabs to indent to the block level and spaces for further indentation, like so: { <-tab->a = long expression <-tab->____continued; }
It does matter, because some tools that are hard coded to 8 space tabs make things hard to read, like side by side diffs.
Also, I have used editors, like the AS/400 editor SEU, which displays a single inverse block character for tabs. It was pretty much impossible for me to maintain that code until I converted the project from tabs to spaces.
Re: (Score:2)
I use tabs because anyone can set the width to whatever they like (2, 4 or 8 spaces usually).
That only works if you're also careful to use spaces for all additional indentation used to line things up -- and in many cases lining things up can significantly improve readability.
I used tabs for base indentation (to the block depth) and spaces for extra indentation for a while, but even with good editor support I ultimately decided that it just caused me to spend too much time playing with whitespace.
If you want your code to look good no matter what the tab width is there's only one practical way:
Re:Kinda Subjective but... (Score:5, Insightful)
a tab is a tab. It is not 8 spaces. It might be the same width as 8 spaces, but that is because your editor displays a tab as that width. Most editors allow you to change it.
If your code style calls for tabs, do not insert 8 spaces instead of a tab. it's annoying, and you break the tab settings everyone chose for themselves.
Re: (Score:2, Informative)
Re:Kinda Subjective but... (Score:5, Insightful)
man expand
read it.
And your post is exactly why people standardize on spaces. Because some people think they can insert a bunch of spaces instead of a tab, breaking everyones formatting, making diffs a huge mess and putting your whitespace changes in the commit log. Tab is not space.
A space is ascii # 32
A tab is ascii # 9
stop mixing them.
Re:Kinda Subjective but... (Score:4, Informative)
no, it's you who broke the formatting by mixing whitespace characters.
and you don't want to type "| expand -t4", so you're going to make a mess of the commit log, make diff a mess, and force everyone else to run everything through indent.
It's sloppy and inconsistent.. and you're making it harder for everyone else on your team because of your laziness.
Re: (Score:3, Insightful)
Seriously, what the fuck are you doing that depends on the exact way that tabs are displayed by other people!? Why would it possibly be that important? Just how fragile is your workflow that it's broken by someone else's display metrics?
Maybe you need to take a long hard look at your toolchain, then throw it outside in a heap and set fire to it.
I've been using whitespace-insensitive diff and merge tools since the 90s, and I reformatters since 2001 to solve even the largest formatting inconsistencies. There
Re: (Score:3)
Ok... I've figured out the problem: you have no idea what you're talking about; do not understand the differences between whitespace characters; and/or don't understand the settings of your own editor.
There is a difference between setting "replace tabs with X spaces", and "display tabs as X spaces"
Re:Kinda Subjective but... (Score:4, Insightful)
Re:Kinda Subjective but... (Score:5, Insightful)
Tabs for indenting, spaces for alignment. Makes sense logically too, because those two functions are fundamentally different.
I.e. it should be:
<TAB>int_a;________//_Hello
<TAB>int_whatever;_//_Yeah
Where <TAB> is a tab and _ is a space.
Works beautifully. Think, people!
Re: (Score:3)
Are there really people who get their jollies by changing the tab value to make code look different on their screens
Yes.
And why should anybody pander to your bizarre fetish?
Use Unix "unexpand" and shove in tabs everywhere you want. Whack off while changing the indents; I don't care. But for the source code I have to deal with, why must I try to figure out what particular tab setting made you orgasm?
If you are truly obsessed with a 7-space indent, then go ahead and use that but don't make me have to try to guess it.
Re: (Score:2, Informative)
Tabs indent, spaces align. Your code should look equally good no matter whether tabstop is three characters or eight.
Re: (Score:2)
Tabs indent, spaces align. I do this with my own code too. When I use different editors with different tab settings, I often don't even change the tab setting, my code still aligns nicely, just bigger indent. And this is from someone how loves to align things, even inserting spaces or changing variable names to get all "=" nicely linked up in variable initialisations.
Even when I break lines (on my small netbook screen), use the appropriate number of tabs to match the indent, then align the
rest with spaces,
Re:Kinda Subjective but... (Score:5, Insightful)
Out of curiosity, why do you prefer tabs? Seems like unless everyone has the same tab size set, it can make the code more difficult to read than spaces.
For the same reason why CSS was invented to style HTML. Tabs are entirely font-agnostic and they are semantic. Spaces are not, and are directly visual.
There are people who like two characters of indentation and there are those who like eight. Some like six! There are people who like proportional fonts for coding. There are people who like special narrow monospaced pixel fonts. Even Consolas on Windows, a very popular coding font, is narrower than the standard monospaced width, so code is less indented with Consolas than Courier.
Tabs are also easier on the eyes if you have "show special characters" turned on in your IDE. Also, tabs are easier to work with if you ever need to run some regex on your code.
There are no benefits whatsoever to using spaces, only downsides.
Re: (Score:3)
For the same reason why CSS was invented to style HTML. Tabs are entirely font-agnostic and they are semantic. Spaces are not, and are directly visual.
We're talking about code here. Is anyone using anything but a monospaced font when viewing it?
Re: (Score:3)
We're talking about code here. Is anyone using anything but a monospaced font when viewing it?
Yes, plenty of people. I was using a proportional font for a while when I had a low-res monitor and needed more stuff on the screen. I have two coworkers using proportional fonts right now.
What is readable to one person might very well not be readable to someone else. That is why some people like their code on black backgrounds and some will get severe eye strain if they look at white-on-black for a couple of minutes.
Nevertheless, see the post above about monospaced fonts wildly differing in character width
Re: (Score:3)
Yes, plenty of people. I was using a proportional font for a while when I had a low-res monitor and needed more stuff on the screen. I have two coworkers using proportional fonts right now.
I havrn't seen this first-hand, so thank you for the information.
(I'm not being snarky - and on Slashdot I do feel the need to say that!)
Re:Kinda Subjective but... (Score:4, Interesting)
Here's the funny thing, and I'm honestly not joking: one of these guys is using Comic Sans as his coding font, as he's dyslexic and it helps him. The other is using Tahoma, because it's very narrow.
Visual preferences vary. That is why we are able to set our own fonts and colours in our IDEs. It is strictly a personal thing. I'm a black-on-white guy, but the Tahoma guy from above is using the old Borland nineties colour scheme, yellow-on-blue. Strangely enough, I "grew up" on those same colours, and since switching to LCD monitors, I can't stand it any longer. No idea why...
Re: (Score:2)
Yeah, I remember that. Always thought it was ugly, but it seemed to be pretty readable on CGA.
Gotta agree on the whole tab thing. Logical code indents should be tabs. Thankfully I'm in charge of coding practices (and everything else) at my place, so yay we get to do it :).
Re:Kinda Subjective but... (Score:5, Informative)
one of these guys is using Comic Sans as his coding font, as he's dyslexic and it helps him
Has he looked into fonts designed to help dyslexics, like Gill Dyslexic [pixelscript.net] and Open-Dyslexic [dyslexicfonts.com]?
Re: (Score:3)
Some people don't even use a font- I work with a blind programmer. He uses a screen reader.
Re: (Score:2)
Yes, when you have your HTML editor set to show 2 character indents for tabs, but your browser's 'view source' option shows it at as 8.
Besides using a non-monospace font, it will always look the same no matter what editor you (or someone else) brings it up in.
Flexibility has it's downsides, just as being too rigid has its downsides.
It's a choice. Most people pick one and stick with it.
Re: (Score:2)
There are no benefits whatsoever to using spaces, only downsides.
Until you want to evaluate some code, and paste it into some console which treats tab as auto-complete. I generally much prefer tabs, but this behavior drives me nuts, and has in some cases pushed me to spaces--and now I'm remembering how much I hated all the nonsense with spaces...
Re: (Score:2)
Re: (Score:2)
Well they are clearly superior. That is the entire point of a tab. Why use the space character as a crappy replacement when you have tabs.
Learn one word (Score:4, Insightful)
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.
Let people code how they like (Score:2, Insightful)
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
Re: (Score:3, Insightful)
Note to self, don't hire this one.
The reason we enforce code style is the same that we enforce requirements traceability. We must have maintainable, auditable code. If we were writing throwaway scripts to delete old comments on a website, perhaps that would be okay. However, when we're writing production code that needs to work and be maintained, code style is very important. Yes, we audit code. Yes, it works. We have yet to have gotten hit with a real-world exploit, critical bug or unexpected behavior from
Re:Let people code how they like (Score:4, Insightful)
Note to self; don't work for people who don't have a real account on Slashdot.
Seriously? How is having a slashdot account a positive personality attribute? Were you too busy reading the articles to notice what gets posted here?
Re: (Score:2)
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.
It depends. Some people here seem to be defining "readability" and "documentation/comments" as coding style - and I do think readable, well-commented code is important.
Otherwise I tend to line up with you. I will admit, though, that I've never been part of a large group jointly working on a software project. When I'm dealing with another person's code, most of the time it's something another person wrote by himself, and I'm now having to add some feature or fix some bug after the fact.
Re:Let people code how they like (Score:5, Insightful)
Coding style is not just be about making code look pretty (according to someone's personal definition of pretty). The purpose of a coding standard is to make the code more readable and thus, more understandable. Having the code look consistent helps in that regard.
Most of the time as a programmer is not spent on producing code but on skimming through other people's code and trying to figure out how something works, or why something doesn't work. Time is money, and it is better that a code writer spends a few extra seconds on making the code more readable than a code reader spending maybe fifteen minutes on the same piece of code because he misunderstood some detail of it the first time around because it was written in a weird way.
There are some things that are more important than whitespace and braces, that are too often overlooked. A coding style/code standard should also include conventions for code patterns, comments and how to choose reasonable variable names ... and these things can not be changed by a "pretty printer".
Re: (Score:2)
I've never seen how to choose variable names or when to comment in a coding style. Typically, people are expected to just know that. Every coding style guideline I've ever used has been nit picky bullshit about braces and spacing, enforced by that one anal retentive asshole every workplace seems to have.
Re:Let people code how they like (Score:5, Insightful)
No, really he's not. I am quite capable of reading code with different indent styles, brace styles, etc. I do so on a regular basis, even when working with language approved styles as I regularly program in multiple languages. I have no trouble with it mixing program to program, file to file, or even function to function.
In fact, most code bases I've worked on looked like that. And there was no noticable speedup in places that did enforce a style vs those that didn't.
In fact, he actually tends to harm code quality. Why? Because he bogs down code reviews. Rather than looking for serious maintenance or correctness problems, we focus on his half dozen style complaints. This wastes our time and causes people to hate code reviews, or take them less seriously. The places I've worked with style guidelines all had shitty code review processes, and this was the reason.
So no, that anal retentive asshole made everyone's job far worse. There are code style issues that matter, like naming variables well and commenting sufficiently. Formatting is not one of them, and being particularly picky about it is a BIG red flag about both a person and a company.
Re: (Score:2)
The purpose of a coding standard is to make the code more readable and thus, more understandable.
That is EXACTLY why you should let people code the way they like, as long as the way they code is consistent.
Developers have a natural coding style they find more readable, letting them work on code they find more readable is beneficial in development.
When you are done, yes you will find modules where code differs in look. But that does not really matter; generally code is understandable by those coming along l
Re: (Score:2, Interesting)
I do not see any point in coding styles whatsoever.
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; in fact you have probably never worked with revision control tools ever in your life.
please allow me to know exactly who you are so that i never, ever employ you or allow you to go anywhere *near* any of the free software projects i am involved in or will be involved in,
Have worked on MANY large teams (Score:3)
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 probab
Style has always mattered (Score:2, Insightful)
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.
It depends on whatcha mean when you say style (Score:2)
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
Re: (Score:2)
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.
Until source control systems work on semantics and not textual diffs, it is not as simple as that. If I get your code, reformat it to my style, change 2 lines and check it back in, I have completely polluted it as far as a diff goes.
If you want to have a rule that says all code gets run through a formatter prior to check-in, that would work, but it would mean that everyone would spend lots of time converting to and from the approved check in style.
Re: (Score:2)
I'm not advocating this, but it's simple enough to do this with, say, automatic git hooks (pre commit, reformat the code, on checkout, format it back how you like it). No extra work on the developer's part.
Re: (Score:2)
Re: (Score:2)
Unless you use a version control method which can autoformat on checkin and checkout
Re: (Score:3)
Seriously? You are reading the code, fixing bugs, and you find formatting problems. So you back out your half-complete changes, fix the formatting, commit that change, then re-apply your fix-in-progress?
NO. What part of dedicated commit for formatting changes do you not understand?
You never leave changes from a previous session uncommitted; always commit all changes before leaving the desk.
Before you start working on any code, you update your working directory from the repository. You correct any
Python Indentation: Style is the language (Score:2)
Python Reference Manual: 2.1.8 Indentation [python.org]: 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-bla
Re: (Score:2)
Which is all fine and dandy if your company primarily writes code in Python where the whitespace is a fundamental part of the language. For everybody else who has to switch between C++ / Java / C# / CSS / HTML / SQL / JavaScript / Perl / PHP etc. and doesn't use Python *at all* there are "best practices" for coding style in each, most contradicting each other.
Re: (Score:2)
And that's why I've wasted weeks of my life fixing Python bugs due to developers using different amounts of spacing. Python took the worst possible path- requiring whitespace to have meaning, but not requiring a specific type/amount of whitespace. Had they made n spaces the requirement for an indent and anything other than n an error, it would have been fine. As it is, it's completely broken and a large cause of errors on every python programmer with more than 1 dev I've ever worked on. It's to the poi
Re: (Score:3)
Well maybe that's going to be fixed. Let's see:
>>> from __future__ import braces
File "", line 1
SyntaxError: not a chance
>>>
Nope.
PS: That's real, try it yourself
Expertise Boosting Article (Score:2)
Code style, not formatting style (Score:5, Insightful)
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.
Re: (Score:3)
I like you. There are style things that are important, but it's not how the code is laid out in the editor. Concentrate on the important things, not the things everyone has to deal with.
Re: (Score:2)
As said, coding style on that level is something everyone who writes code professionally can adapt to.
When learning at university I was very focused on writing the cleanest, best coding style possible and that kind of focus has paid off. You end up rewriting code many times but at the end you just get it, your code feels right and people tell you your code is good.
If you haven't spent every day of writing code back in university trying to figure out how to write clean code then you're more than likely one o
Re: (Score:3)
"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."
and that's SO worth the price of admission since it's so hard to achieve that otherwise.
"And if I do go in to "someone else's code" and change or fix things, I follow their style, more or less."
Which really helps everyone tell who wrote the code. ;)
It's amazing how hard people are trying to justify their own prejudices here.
Re: (Score:3)
Well, there's the full SVN history if we want to be sure, and some comments get tagged with an initial (eg. /* @@@@K: this will break if we ever get over 4 million users */ for Kevin saying that we might want to make that a 64-bit int, not 32-bit, at some point). And we use Javadoc (or similar) whenever possible, so we know who's worked on a file.
The code formatting is more of making it *convenient* to know, intuitively, who wrote the code. I can even tell whether it was 2011 Kevin or 2012 Kevin writing the
My two point coding style (Score:2)
1. Use spaces instead of tabs.
2. Make your code readable by humans.
Comment that code!!! (Score:2)
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.
Style is Substance (Score:5, Informative)
The best article that I've ever read on coding style is Style is Substance [artima.com] 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.
Cha-no-yu (Score:2)
The practice of
Run everything through a formatter (Score:4, Informative)
Just use Artistic Style [sourceforge.net] 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.
Style != formatting (Score:2)
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
Re: (Score:3)
Max number of lines in file.
Cyclomatic complexity.
Use of standard design patterns. (factory, singleton, adapter, and iterator)
What subset of the languages commands are not allowed.
Oh yes: it is a good proxy measure of quality (Score:2)
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 inde
KR (Score:5, Informative)
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.
It does matter (Score:2)
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 i
point (Score:2)
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.
style (Score:2)
The compiler doesn't care how you format the code.
Your boss, however, might.
Re: (Score:3)
Your coworkers, however, might.
ftfy
Re: (Score:2)
Get a program to refactor the code into whatever style you want.
Because when you check-in your refactored code to the {git/svn/whatever} repository it shows nearly every line as a change, and makes it difficult to see the one or two lines that actually changed. The repository quickly because bloated with meaningless changes as dueling Aspies engage in coding style wars.
Re: (Score:2)
Re: (Score:2)
styleA(styleB(document)) != styleB(styleA(document))
Re: (Score:2)
Have you ever actually done this?
How does it work for higher-order rules like the example I mentioned (where the program would have to determine programmer intent)? How about naming conventions, some of which may even be lossy in conversion or impossible to synthesize mechanically?
You may be able to use a "refactoring program" for brace placement and spacing, but coding styles are much more than that.
I'm not advocating for a rigid enforced coding style (at all), but it doesn't make sense to defend not havin
Re:Instant Code Style fix (Score:5, Funny)
Ctrl+K, Ctrl+F
Presto, you've got your coding style for code that you didn't write.
Doesn't work for me. Ctrl+K deletes the current line, and Ctrl+F moves the cursor forward one character. What version of emacs are you using?
Re: (Score:3)
Poor or inconsistent coding style, OTOH, gets in the way of producing correct, working code. If you have to constantly stop to figure out how the current statement's nested or which block it's in, that takes time and attention away from concentrating on what the code's supposed to do. That means more errors, more bugs, more time debugging and a greater likelihood of missing bugs or a deadline or both. If I look at code and find no consistent coding style in it, that tells me that either the programmer didn'
Re: (Score:3)
Code style can, however, make it easier to spot typos when you make them, easier to scan for them. Eg. the regexp "if .* = " to spot use of an assignment inside an if condition, which is normally a bug. If you consistently use whitespace between tokens, it's easy to write that regexp and have it reliably catch all occurrences while also reliably not catching anything else. If you omit the whitesp