By SoftwareProjects
via softwareprojects.com
Published: Sep 18 2008 / 02:35
By SoftwareProjects
via softwareprojects.com
Published: Sep 18 2008 / 02:35
Comments
cherouvim replied ago:
hungarian notation looks really bad
SoftwareProjects replied ago:
cherouvim, there’s still a tremendous amount of value to Hungarian notation, in that it increases collocation in code, which makes the code easier to read, write, debug, and maintain, and, most importantly, it makes wrong code look wrong
,
SoftwareProjects replied ago:
Great additional comments on the thread on our website
Thank you everyone for sharing your thoughts about this.
mvonballmo replied ago:
Marked down for these beauties:
"EVERY SINGLE LINE of your code must be prefixed with a // comment. There is no exception to this rule."
and
"...a [b]nonprogrammer[/b] reading your comments [...] should be able to fully understand what the function is doing."
Yeah! Um, no.
SoftwareProjects replied ago:
Thanks mvonballmo. We appreciate your comments
maxk42 replied ago:
This is truly irresponsible advice. Some of the worst programming practices I've seen espoused in a long time and a terrible marketing piece. After lurking for two years, I signed up to dzone just to warn novice programmers NOT to take the advice in this article.
jerryji replied ago:
"""All integers must be prefixed by a lowercase i, followed by first letter of every word in caps."""
Or even better -- "All variables begin with letter between 'i' and 'n', both inclusive, are of type int implicitly (and curse Java for not enforcing it in the VM!)"
SoftwareProjects replied ago:
@maxk42, thank you for your passionate comments. If you don't like Software Projects coding convention, you definitely don't have to adopt it. Works great for us.
Your dzone profile shows you joined dzone today (9-18) and posted three negative comments. Hope you find something you like on dzone.
@jerryji - didn't get your point.
dragmire replied ago:
I think a more informative article would be to reference one of the standards already out there and the list your differences. I'm more likely to ignore a "soapbox" article than an active discussion, as it looks like someone trying to drive up hits rather than actually be a part of the community.
Also, horrible advice on the comment requirement. I agree with mvonballmo there.
SoftwareProjects replied ago:
@Dragmire, this coding convention is the one we use here at SoftwareProjects.com
You're welcome to adopt or ignore. This article was not posted as advice. Title is "Software Projects Coding Convention". This is the convention we use here internally. Would love to learn more about the coding convention other people use and see if there's anything we can use. We're always looking to improve.
Didn't get your comment about "driving up hits". Our page has no adsense code, no banners and no buy now buttons.
Thanks again for your comments.
Topnotch replied ago:
In my opinion a developer should know how to design clean and understandable code without being shackled with so many arbitary coding conventions. Trying to remember all this crap is a real drag on productivity too. You may think that this is working for your developers but have you really asked them what they honestly think?
SoftwareProjects replied ago:
@topnotch, we do commercial projects for 3,000 businesses in 14 countries.
This is not a democracy.
These coding conventions are the result of 200 engineers writing code for our clients over the last 10 years. Every single rule on our list was "written in blood" as the saying goes. Every single rule is the result of our evolution since 1998.
We'll be writing a few posts about the tools and techniques we use to manage large distributed teams of engineers, all working on commercial projects where "time is money", coding under the extreme programming methodology where your code goes to production right away. (Very different from doing open source)
In such an environment, one of the most important lessons we've learned is that you want to do everything possible to eliminate the potential for human error.
STL templates, exceptions and class inheritance are all great tools but often too advanced for the average engineer to comprehend.
To keep things manageable and reduce the likelihood of human error. Think of it as a way of sticking to the lowest common denominator.
Voters For This Link (6)
Voters Against This Link (20)