You might want to consider building a hook into your source control setup so that code gets auto-formatted before it gets into the main branch.The Eclipse formatter has built-in rules to match these conventions, which should also help.A lot of public libraries and open source projects tend to use these conventions, so when you need to look at those the formatting should be familiar.Using these should help you avoid arguments about which style to follow.Oracle has published a set of conventions for Java, which are the de facto standard.I just wanted to add a couple of points which haven't been used elsewhere:
Yes, consistency is a good idea, for reasons others have mentioned. So while there are good reasons to impose a specific style and standard, there's as good reasons to not do so (too) strictly. They're also going to be in the habit of writing clean code simply because that's what works, even if there are small differences between their natural styles.
experienced programmers can be much more productive if they don't have to think half the time whether what they're writing will "look right" to the automatic approval system, or the reviewer. So don't go around reformatting existing code when someone changes a single line in a 1000 line file. And that means code sections as well as entire source files. never change existing code for the sake of changing it, you're only introducing new problems that way. Some even mandate these standards (think Python, Cobol, Visual Studio automatically imposes C++ style bracing conventions while Java uses C style by convention, etc. Different languages have different standards people are used to who're experienced in their use. I've seen "code standards" enforcing the number of spaces of whitespace between in comment blocks, the alphabetical ordering of method names, and other nonsense. _hUngarian_lpfstr notation being a prime example :) a common look and feel to code can indeed help make code more readable, but also can make things worse if it's the wrong look and feel. What are you trying to gain, how anal retentive are you going to be in enforcing it (and in the level of detail your "rules" will be set out), are you going to try to enforce it on code written in different languages, are you going to try to enforce it retroactively on existing code? The best case scenario is if you can start enforcing the settings right from the beginning of a project. The only argument against common code formatting settings that I can think of for your case is that it's apparently an already ongoing project, so it will cause lots of unnecessary changes in all the files, messing up the actual file histories. Then you have to think about stupid and meaningless issues such as if it's OK to modify somebody else's code in your own style, or if you should try to imitate their style instead. I have also worked in projects where everybody has had their own styles. It's care-free, like writing documents with LaTeX: it's formatted afterwards and you don't have to worry about it while writing. I find it comforting that I don't have to bother myself with thinking about the code formatting, as Eclipse will do it for me automatically when I save. Those being the main reasons, there are others as well. The code becomes more anonymous and common property, so nobody needs to feel uneasy about changing "somebody else's" code. With everybody formatting their code the same way, you can no longer as easily tell who has written what. The second reason is that it kind of takes the programmers' egos out of the equation. No more just adding or removing a space here or there, let alone reformatting an entire file as a "side effect" of actually changing just a line or two. 
First has to do with version control: with everybody formatting the code identically, all changes in the files are guaranteed to be meaningful. I'd say there are two main reasons to enforce a single code format in a project. ) As a related side note, with the common formatting rules we also enforce certain, rather strict compiler warning settings in Eclipse, with most of them set to Error, many set to Warning, and almost none set to Ignore. As a new member of the company I found that the common formatting rules gave me a warm and fuzzy feeling that "these guys know what they are doing", so I couldn't be happier. I currently work at a place where a standard code format is enforced and the code is automatically formatted when saving the file, just like you are about to do.
0 kommentar(er)
