Recently, I've been switching between several projects and development environments. The expectations for coding style in each is different.
Now, my question is three part, the first, just of curiosity:
№1. # How did you define and find your coding style?
Through code samples first in books, then in MSDN texts and articles, then blogs and other web sites.
№2. How do you keep augmenting and improving it?
I keep my eye open to all suggestions people make. I try them out, if they work for me, they stick. I also experiment from time to time, what seems to improve things stays with me.
№3. How do you maintain it? (From mental notes, keeping a document, using a tool like StyleCop etc.)
I sort of remember my style and apply it automatically everywhere.
Note 1. Keeping an eye open and an ear sharp is extremely important to stay current. Years ago I learned from others the Hungary notation was a must so I followed it. When the community realized it was not so great I changed with everybody.
Note 2. It is often not that important what particular style elements you adopt but rather that you keep your style consistent throughout your codes. The same applies for a team. Choose some style but then stick to it.
Note 3. Coding styles for different languages may vary. C++ deserves one style, Java the other. HTML and CSS have their characteristics require some different style again.
Note 4. Whatever style you choose, understand and accept that it won't work 100%. Sometimes you have some code that requires a different style just in-place, either split multiline, different alignment or whatever to keep that particular code piece more readable. Don't push your style everywhere, focus on the code readability. If it is obvious, the style doesn't work in this particular place, make an exception.
Note 5. Don't make following a code style to a religion. Tools enforcing a code style are good, but sometimes can make you mad. I for instance disabled the Visual Studio's automatic code formatting because it was driving me nuts. If a tool becomes an obstacle, just add an exception and don't worry that your code isn't 100% compliant. It's not that important really and perfection not achievable is anyway.
I dont think there was a time where i said: "Ok this is going to be my style". Do focus on specific environment or language. Your style should reflect the way you face a certain problem.
I worked in a team with a closed source game that I loved and the lead developer mentored me, and helped me improve my skills after I asked him too.
He suggested, and I adopted the Zend Framework's Coding Style (http://framework.zend.com/manual/en/coding-standard.html)
I ended up adopting characteristics of different styles - including styles reflected on MSDN. I then set up templates in VS that provide my #region/#endregion blocks and anything else that is preferable.
I continue to study other styles that I encounter through research and reading. If I think there is something that stands out and could improve my style in readability, maintenance, or organization, I try it out. If a new style adjustment is in order, I will update templates in VS or make mental notes.
When coding alone, I aim for brevity; Spartan Programming may be complete, batshit insanity... But it's probably the closest familiar thing to my creed.
When coding with others, especially maintenance coding, I aim to be a chameleon - my changes should improve what they modify, without looking out of place.
How did you define and find your coding style?
By focusing on simplicity and readability (readability !== understandability, see Spartan Programming)
How do you keep augmenting and improving it?
By reviewing others' and my own code (and even coding standards themselves).
How do you maintain it? (From mental notes, keeping a document, using a tool like StyleCop etc.)
I use dokuwiki, a breeze to setup (no database), hierarchical structure, granular control (ACL out of the box), really nice looks, and well, its a wiki, so anyone can contribute. Also, contributions/changes are always under consensus and justified, based on simplicity and readability.
This is kind of a weird answer, but I took a really long time to actually pick up programming. I spent a lot of time working in 'the arts' before considering myself a programmer.
When coding, I tend to think in units like writing - paragraphs, phrases, etc. Because of this, I'll spread code out over more lines in the pursuit of making it readable like a story/essay/etc. I get really annoyed when developers try to cram as much as possible onto one line or into a small space, because it doesn't accomplish anything besides making the writer feel clever and annoying any future readers.
If I need to do something weird for the sake of efficiency, I'll comment it to explain why it's like that.
I probably won't get any upvotes for this but perhaps this will spark some discussion anyway.
As for the technical side, like placement of brackets and such, I keep them aligned because the result is increased readability.
1. How did you define and find your coding style?
I go for adopting an already developed style guide that's largely developed and widely accepted or popularized by a large company/project.
I do it for numerous reasons, but mainly because such style guides can be immediately adopted by developers. A style guide is only worth as much as developers are willing to stick to it.
Examples of such are Python's PEP 8, Android's style guide for Java, jQuery Core style guide or Google's Python style guide.
2. How do you keep augmenting and improving it?
The biggest argument for such style guides is that they were Not Invented Here and Not Invented By Me. It took scores of developers, intimidating lines of code and more time than your company/team would ever be willing to invest into developing and maintaining a style guide.
As for improvements, there's never been a style guide that immediately answers everything you may need to know. But, in most cases the improvements that I've seen being pushed forwards were just a more verbose version of what the style guide already paved out with it's approach to writing code.
In such cases when you run into a block of wierdness, you should paste it into a gist or into some other appropriate code snippet sharing tool with color-syntax support and discuss it somewhere with other developers. Great thing about is that in such instances your not interested in what the code does, but just how the code appears, so you can take that block out of context and discuss how you should go about improving it, comparing it to what's already specified in the style guide as the main starting point for discussions.
3. How do you maintain it?
Well, the great thing is that you'll already have existing documents that are publicly maintained online.
When it comes to code formatting, you can also go the extra mile and provide your team with formatter configurations for their favorite editor, which should take out the crud and guesswork on maintaining tip-top appearances. Actually, I wouldn't call it going out an extra mile, but an integral part of development--there's nothing worse that doing a diff where 90% of code changes was someones check-in of properly formatted/styled code because someone forgot to clean up before they committed a huge new feature.
If you are part of a team, you should always adder to the team's standard. There is a lot to be said to use a generic layout and not your own personal one. It makes your code easier to read and understand by others which is essential.
