|
Coding Standards
After reading what Chris Sells wrote, I too had flashbacks to when I was beginning a new project and wanted to have a firmly established coding and formatting conventions. I clearly remember when I first came Groove Networks and read one of the few documents for naming techniques in C++ - pretty simple rules:
- No hungarian notation except 'p' for pointers and 'pp' for pointer to pointers
- Proper case variable and method names
- All input, output and input/output parameters would have prefixes of 'i_', 'o_', 'io_" respectively
- Global variables are prefixed with 'g_' and member variables with 'm_'
It took me a few days to get in the flow of prefixing method arguments appropriately, but it wasn't that big of a change.
As for formatting guidlelines, the only one I was aware of was that curly braces were always on the next line and indented under if/while statements and method definitions. Now having come from a long line of outdenters and I honestly thought my world was going to end when I saw this "messed up" layout. How could anyone read this? I'll never get used to this - it's just so wrong. Long story cut short - it took me about 4 days to get used to it. In fact, by 2 weeks outdented seemed "messed up".
So here we are several years laters and where do we stand with formatting and naming conventions? During the course of hiring more engineers, each with their own formatting style, we too adopted the "When in Rome" policy.
The only thing I am still disappointed about is that Rome looks different from person to person, and when developing a platform that requires editing source code in multiple files in multiple projects, it is a major pain in the ass to constantly adjust your formatting style.
I am now of the mindset that when a project begins, the manager should define the coding and formatting conventions and force every developer on the project to adhere to them. Some colleagues have called this a "draconian" approach to software development - and you know what, maybe it is. But the advantage of being able to flow between source files and not skip a beat is too compelling for me.
Typically developers are resistant to follow any style that is not their own and/or they feel like their artistic license is being squashed.
<Rant> Suck it up. Your primary responsibility to the company is to write quality code. You secondary responsibility to the company is to write maintainable code. If you're a reasonably talented developer, it will take you about 2 weeks to adopt a new naming/formatting convention </Rant>
By the way, for those who have elected to use products that can enforce formatting rules - I don't know if you are doing a service to anyone. I say this because on numerous occassion I have had to use other people's machines for debugging purposes as well as making source code changes, and each one has a different configuration of installed software. I believe that the adoption of standards has to be done by the developer, not enforced by software.
So as we head towards the .NET world and embrace C# - it turns out that there are suggested naming conventions (camel hump) for developers. Hmm... lowercase letters for the beginning of variables names - that looks messed up...
12:47:40 PM 
|
