|
The question was about style the answers were about standards. Two different things. I have a personal style but no company standard (yet).
|
|
|
|
|
That's exactly it.
People are debating the wrong stuff here.
Everyone has its own style of coding. It may not be original mas is his/her way.
Following standards has nothing to do with this.
|
|
|
|
|
I agree. The trouble is that coding standards often include style, so that doesn't help in not getting them mixed up! Standards (excluding style) are more important than style. Although I have a preferred style I would make more fuss over things such as not using magic numbers than code layout.
Kevin
|
|
|
|
|
The first I do in any class or module is create sections for Storage, Properties, Constructors and Methods. Sections for event handlers, interface implementations, internal classes, enumerations and the like are added if needed. If the code is really complicated, I'll use subsections, like separating public and private methods, or grouping menu handling events away from other controls. In each section, the methods are sorted alphabetically. With this setup, I can look at my code years later and know what is what, and even find stuff faster than I can navigate the search functionality.
|
|
|
|
|
... and this is not necessarily bad.
At this main project I'm involved we work together for more than 4 years now and we can distinctively identify who's code is that we're reading.
It's not an immense difference but it shows.
Its king of a "personal touch" we all have.
It may be the way we use the brackets, we declare the variables, the actual naming, the way we write JOINS on SQL Server (if we break line on the "ON" or even if it breaks before or after the "ON").
It has nothing to do with good or bad code, it just the small things that if we know each other well we can identify who wrote it.
I think that on a team we all should follow the same guide lines but enforcing too many rules we may end up killing creativity/evolution.
|
|
|
|
|
AlexCode wrote: if we break line on the "ON" or even if it breaks before or after the "ON"
Definitely before the ON.
|
|
|
|
|
...on which project I'm working. At work, we use the recommended MS style. There are even some checks on the TFS for that.
When working on some open source projects, I usually have to follow a different style rule.
|
|
|
|
|
embix wrote: When working on some open source projects, I usually have to follow a different style rule.
Would those be the horrible GNU standards (especially for automake/autoconf) that render projects unnecessarily arcane to the non-initiate?
|
|
|
|
|
|
Hi,
Most of the software engineers I have worked with adopt the coding style of the project. For example... I have participated in several open source projects... Those projects using the boost framework and modern C++ seem to mostly use BSD style indent/braces and multi-word/underscore naming conventions. I notice that the MFC projects are mostly using BSD brace/indent and hungarian notation. Many of the older C projects seem to use the K&R brace style and camelcase.
When I contribute to a project... I adopt the coding style of the project. I suspect that a large number of engineers do the same.
My personal preference is the BSD style brace/indent and hungarian naming. There is actually a story behind this... ALL of my C code before around 1998/1999 was written with the K&R style brace/indent and camelcase. When I switched from the Unix platform to the Windows platform... I made a conscious effort to change my coding style... I remember it was very difficult at first to break my K&R habits... and it took over a year for the BSD style to feel natural.
I find that variable naming makes absolutely no difference. I can read and interpret all styles of variable naming convention at the same speed. However... I do believe that the BSD style of brace/indent is superior... it allows me to immediately determine start and end of scope and loops. Conversely when I am reading K&R style code I sometimes have to spend a few seconds scrolling up to find the start of the scope/loop.
Best Wishes,
-David Delaune
|
|
|
|
|
|
Yes I do follow strict coding standard, naming conventions, variable declaration etc. Thanks to my TL, At the beginning of my project i felt it time consuming, but now when it becomes huge application after 8 months it becomes easier for me because of uniformity we have maintained all over. Its really much better, to follow standards strictly.
|
|
|
|
|
I also follow strict coding standards!
|
|
|
|
|
Everyone has their own style and no one's style is like the next persons. If you work in a shop or with another team, then you all are supposed to stay on the same sheet of music...in theory, not always in practice.
duh
"the meat from that butcher is just the dogs danglies, absolutely amazing cuts of beef." - DaveAuld (2011)
"No, that is just the earthly manifestation of the Great God Retardon." - Nagy Vilmos (2011)
"It is the celestial scrotum of good luck!" - Nagy Vilmos (2011)
"But you probably have the smoothest scrotum of any grown man" - Pete O'Hanlon (2012)
|
|
|
|
|
Slacker007 wrote: Hasn't this been debated in the Lounge, Ad nauseam?
Yup. Should be enough to fill a book by now.
"Cumulative thoughts on Coding Style from CodeProject-members, Volume I."
Slacker007 wrote: If you work in a shop or with another team, then you all are supposed to stay on the same sheet of music...in theory, not always in practice.
..yup. Old cake, but there seems to be a never-ending supply of people who preach Apps Hungarian, that don't count inline-comments as style and who don't share common patterns.
Bastard Programmer from Hell 
|
|
|
|
|
Me, I like nice structured code with plenty of comments. So I have no problem with following reasonable code standards. (Nowadays I get to write them so of course they are reasonable ;D )
Some of our customers insist on our following code standards. Part of my job at the mo is making sure we do, using code checkers and so on. Which can cause problems, because PC-Lint, for example, may insist on changes which gnu, for example, will flag as errors.
------------------<;,><-------------------
|
|
|
|
|
Once a standard has been adopted it should be followed, but that should not preclude changes.
I am yet to see [in 25+ years] a standard that has not changed. As the code base evolves and the understanding of the developers increases, the standards do need to be adapted.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
The most important thing is to realize that we are talking about things that have no direct influence on the project's outcome. The compiler does not care very much about code style as long as it is syntactically correct. Readability and standards are important to let a team work on the project efficiently, but not so important that those standards must be enforced at all costs.
My worst experience was a project where somebody went a little overboard by installing a tool similar to Style Cop and setting the strictest style rules and treating all violations as errors. I personally don't like to write code based on assumptions. When the documentation does not help, I simply test my assumptions with a few lines of code and the debugger. Simple enough, at least as long as there is no dumb tool that keeps on complaining about your quick and dirty test until you have not styled and polished everything perfectly. That tool is supposed to assist me, and not to harass me into styling code that I am going to throw away in a few minutes once I have what I wanted to know. Nobody needs an automated clueless smarta$$.
The other thing is to define exactly what 'readable' actually means. My native language is not English and variable names that don't start with a capital letter, like camelCase, always distract me from the code I'm reading. I'm used to all nouns being capitalized and it's a hard habit to break when encountering variable names that don't do that. Readability obviously is a personal thing, and therefore it's futile to try to enforce some supposedly global rules. A team should simply agree on a style that suits its needs, use and adapt it with good will and simply see over occasional violations.
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
Abso-bally-lutely! The style is to help the devs NOT to provide some stupid metric.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
I like a good structured, commented, readable code. So I do it as I would like it to receive from others, but I don't change the structure of a software that is already done.
If I start it from the beggining, it is OK. But if I get something I have to fix, to complete or to add new features. Then I try to do it following the same structure it already has. I know , someone will say that is not good, but it is already enough having to introduce myself in the structure of a previous programmer. Having to do in different structures... would be worst that a kick on XXXX (Kid sister's rule). So I try to make it as close as possible.
But this is not the only reason.
In the industry world, to change the structure of a software (no matter how bad it is) can give you a lot of problems with the maintenance people, because they are used to it, and... if maintenance people start saying bad things about you, you can lose the client. So... before changing anything... Ask and Reask (and if you can get it on paper... even better).
Regards.
--------
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpfull answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I do follow a consistent style, line spacing, naming convention, groupings, tabifying and few more, It makes a lot easier to read and understand...
|
|
|
|
|
...and so do all reasonable programmers. Unfortunately we frequently disagree on the details.
IMHO, such things are just style - I look forward to an age where we can apply styles to code in much the same way as we use CSS on HTML, allowing different programmer's on a project to work in their own style.
Of course, this can only go so far ... identation, whitespace and tabs, and similar (mainly lexical) conventions can be handled easily, while issues such as variable naming are more recaltricant - its harder to automagically convent between approaches.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
