Intervention: Coding Guidelines
-
I like standards. I'm button-down that way.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
Shouldn't your user name be in Title Case?
- I would love to change the world, but they won’t give me the source code.
haha
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
You said it ;) It's all too easy too write reams of code that is almost unmaintainable, in the end readability is more important than performance I think, that way less bugs will be introduced.
I totally agree. I forget who, but someone said that design patterns are just a reflection of the limitations of a language. In other words, patterns should be able to be replaced by keywords, basically, that do the patterns. In general, I think this speaks to the broader point we were on. Let the language do the heavy lifting. I just wish it did more sometimes. I don't often admit this in polite company, but I'm a fan of pure visual languages like FlowStone. They I think, do a really good job of encapsulating a lot of patterns.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
The problem with coding style guides is that they try to put everything in it. Just start creating one with only a few guidelines that are easily enforceable.
I'd rather be phishing!
The style guidelines for my group are a little over one page in length, and are mostly naming conventions. I can summarize them as follows:
- Names should not rely on tribal knowledge for interpretation (use whole words).
- Non-local names should use Pascal or camel case.
- Local names should be in lower case.
- If it's public, capitalize the name.
- If it's private/protected, prefix the name with an underscore.
- Acronyms embedded in a name should be prefixed and/or suffixed by an underscore to ensure the acronym is readable.
- Hungarian notation is strongly discouraged.
- Above all, BE CONSISTENT.
We don't prescribe brace style or other formatting (e.g. tabs), source organization, language features, or most of the other things that people argue about.
Software Zen:
delete this; -
It's a Catch-22 requirement. The rule is to help people who are unaware of the problem it is intended to solve. As soon as you are aware of the problem, you don't need the rule. As soon as you know the rule, you are aware of the problem so are unlikely to fall foul of it.
Plus, any self-respecting compiler released in the last 20 years issues a warning for "assignment in conditional expression".
Software Zen:
delete this; -
Halp! I've become a slave to naming and style guidelines. Years of C++ development and years of development prior to advanced compilers and syntax highlighting and intellisense and doc-comments and all of that made me a fascist about it. To the point where I judge people for not following, say, MS naming and style guidelines for .NET when building C# apps. To the point where I usually kick myself for not putting constants before vars in equality comparisons if(0==foo), etc. I already smoke pot (it's legal here) so how do I loosen up? Y'all don't need my judgment. Nor do any fellow devs. And I need to be able to use other people's code without feeling a little sick about it, or wanting to refactor it before I touch it. I'm half serious about this post.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
I have my own style and coding guidlines, but the determining factor of what I do at work is based on a) Does the company have coding/style guidelines? b) If a is false, I use the style/coding practices of the file I'm editing, and c) try to use the same coding/style as other files in the project in new files i create. Other than that, I try to only have one return point in a method, I declare and ini5t vars at the top of methods or scoped control blocks, try never to use "var" as a variable's type. keep methods within the scope that the method name infers, and I put class components in the order fields, properties, constructors, destructors, and then methods. Ialso put intellisense comments on every method and property. I'm also not shy at all about writinmg copious comments. There are other things, but you get the idea.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
I totally agree. I forget who, but someone said that design patterns are just a reflection of the limitations of a language. In other words, patterns should be able to be replaced by keywords, basically, that do the patterns. In general, I think this speaks to the broader point we were on. Let the language do the heavy lifting. I just wish it did more sometimes. I don't often admit this in polite company, but I'm a fan of pure visual languages like FlowStone. They I think, do a really good job of encapsulating a lot of patterns.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
I have heard about the Ballerina visual language, but never tried it: Ballerina.io[^] Maybe when I'm retired and have the time for it :-\
-
I find coding styles to be like handwriting. When you've read enough code written by others, you'll find that you can read any style - as long as the writers followed it consistently. Life is too short to refactor everything into your preferred style.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
comments are cool, but have you ever implemented an algorithm before you understood it? how do you comment that effectively? for me, what happens is, I code it to learn it. Maybe over the course of weeks, months, even years, depending on what it is I'll refactor or even rewrite as I understand the problem domain better. As I do those refactors and rewrites I can and do add comments. Maybe it's because I think visually so my process to translate algo to code is weird or something, but I'm sure I can't be the only one who does this.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
codewitch honey crisis wrote:
comments are cool, but have you ever implemented an algorithm before you understood it?
This can be taken two ways:
- You're just translating equations to code and are otherwise clueless about its worth
- You're not an expert in the algorithm
Decades ago I translated 4th order runge kutta fit into FORTRAN. As I translated the equations to code I had some idea what it was doing but not really very well. Nonetheless, I could still comment whatever wasn't the most obvious coding translation, or where I twisted it around a bit so it was more efficient. What variables I passed as Globals on one end and where they came from on the other. Comments can be improved as you understand or just learn to code better.
codewitch honey crisis wrote:
but I'm sure I can't be the only one who does this.
True - OCD is not a single degree of behavior. It has a smooth implementation. I, for example, really like my curly-braces to be the way I like them (which visually sets off the code blocks as my eyes prefer it). On the other hand, in SQL, I use recid as my identity column. My 'boss' uses rec_id. Our data is very intimately integrated. As Kurt Vonnegut would say: "So it goes." Besides, we can tell each other's tables apart. We also pick up things from one another - change styles and methods if we decide another is better. No one's ever thought to set up rules for the column names. In fact - I'll use some spin and argue it's better this way: since nothing is an absolute 'given', we're required to pay attention to what we're looking at. Probably saves a lot of profanity down the line.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
I am just trying to let go of some of my uptightness around the standards of others. =) We agree. I mean in principle. Intellectually speaking, but my heart isn't there yet.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Don't want to sound philosophical, but a couple of years ago I experienced a back injury that made it impossible to sit or walk normally for 3 months, which meant I couldn't do what I love doing most - i.e. writing code and building software. During that time I was forced to work from home (standing up, with much difficulty) and participate in meetings remotely. It was during those meetings, many of which included animated discussions (and strong feelings) about coding standards, unit testing and other software development related processes, that I realized what was really important. Yes, of course, I'm talking about one's health. It seems as if I had to experience that injury in order to get my priorities right. I'm still (very) passionate about my craft, but I seemed to have grown a large pair of ears. Today, I tend to be much more sensitive to other people's opinions than ever before. My only regret is, I wish I'd come to this realization earlier. I would've learned so much more from my (much smarter) colleagues. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
I have my own style and coding guidlines, but the determining factor of what I do at work is based on a) Does the company have coding/style guidelines? b) If a is false, I use the style/coding practices of the file I'm editing, and c) try to use the same coding/style as other files in the project in new files i create. Other than that, I try to only have one return point in a method, I declare and ini5t vars at the top of methods or scoped control blocks, try never to use "var" as a variable's type. keep methods within the scope that the method name infers, and I put class components in the order fields, properties, constructors, destructors, and then methods. Ialso put intellisense comments on every method and property. I'm also not shy at all about writinmg copious comments. There are other things, but you get the idea.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013lol i use var as much as possible. in fact, i had to build the habit. if C# had proper typedefs (using doesn't count) then I probably wouldn't, but i use generics a lot
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
The style guidelines for my group are a little over one page in length, and are mostly naming conventions. I can summarize them as follows:
- Names should not rely on tribal knowledge for interpretation (use whole words).
- Non-local names should use Pascal or camel case.
- Local names should be in lower case.
- If it's public, capitalize the name.
- If it's private/protected, prefix the name with an underscore.
- Acronyms embedded in a name should be prefixed and/or suffixed by an underscore to ensure the acronym is readable.
- Hungarian notation is strongly discouraged.
- Above all, BE CONSISTENT.
We don't prescribe brace style or other formatting (e.g. tabs), source organization, language features, or most of the other things that people argue about.
Software Zen:
delete this;Nothing should ever be camelCase. X|
-
Halp! I've become a slave to naming and style guidelines. Years of C++ development and years of development prior to advanced compilers and syntax highlighting and intellisense and doc-comments and all of that made me a fascist about it. To the point where I judge people for not following, say, MS naming and style guidelines for .NET when building C# apps. To the point where I usually kick myself for not putting constants before vars in equality comparisons if(0==foo), etc. I already smoke pot (it's legal here) so how do I loosen up? Y'all don't need my judgment. Nor do any fellow devs. And I need to be able to use other people's code without feeling a little sick about it, or wanting to refactor it before I touch it. I'm half serious about this post.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
codewitch honey crisis wrote:
if(0==foo)
That's the most uselessest concept ever conceived.
codewitch honey crisis wrote:
MS naming and style guidelines
I don't follow guidelines from companies I don't work for.
-
codewitch honey crisis wrote:
if(0==foo)
That's the most uselessest concept ever conceived.
codewitch honey crisis wrote:
MS naming and style guidelines
I don't follow guidelines from companies I don't work for.
It was only useless with the advent of more sophisticated compilers. I started coding in 1986 - old habits. And for the record, I *did* work for microsoft. But more, when you're writing company code that's fine. When you're writing APIs to expose outside of your company you should probably adopt standards for your public interfaces that are widely understood. Anyone writing in .NET is going to be familiar with the style of the 6500+ base classes used in the .NET framework, so it's as good a standard as any for public facing APIs, and better than most
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
Halp! I've become a slave to naming and style guidelines. Years of C++ development and years of development prior to advanced compilers and syntax highlighting and intellisense and doc-comments and all of that made me a fascist about it. To the point where I judge people for not following, say, MS naming and style guidelines for .NET when building C# apps. To the point where I usually kick myself for not putting constants before vars in equality comparisons if(0==foo), etc. I already smoke pot (it's legal here) so how do I loosen up? Y'all don't need my judgment. Nor do any fellow devs. And I need to be able to use other people's code without feeling a little sick about it, or wanting to refactor it before I touch it. I'm half serious about this post.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Try growing up.
-
Halp! I've become a slave to naming and style guidelines. Years of C++ development and years of development prior to advanced compilers and syntax highlighting and intellisense and doc-comments and all of that made me a fascist about it. To the point where I judge people for not following, say, MS naming and style guidelines for .NET when building C# apps. To the point where I usually kick myself for not putting constants before vars in equality comparisons if(0==foo), etc. I already smoke pot (it's legal here) so how do I loosen up? Y'all don't need my judgment. Nor do any fellow devs. And I need to be able to use other people's code without feeling a little sick about it, or wanting to refactor it before I touch it. I'm half serious about this post.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
I am an old programmer. started in 1978. ASM all the way till 2010. yep old school. In 2016 I picked up a gig with a company I left in 1992. Tracking equipment. All C based. No problem. NXP processor. Not bad. MQX RTOS. Bloody night mare. (not an RTOS by the way) Had to drill down and re-write the drivers and part of the OS. The young buck in charge! did not like my style of programming. I did not like his. (macro use every where) Who cares if your style is not liked by someone else. does the end result work? Can someone else follow the code you have produced? If so then job done. Am fed up with programmers trying to copy someone else's style and spending months making it look pretty instead of making a product work using their own style. (if possible) STOP copying and pasting. Without understanding that which you are copying. Anyway. The message is. Develop your own style and progress with that. Ken.
-
Try growing up.
That seems like a childish response, tbh
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
That seems like a childish response, tbh
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
:) Seriously though, when you get older you live and let live. Truths become less absolute.
-
I am an old programmer. started in 1978. ASM all the way till 2010. yep old school. In 2016 I picked up a gig with a company I left in 1992. Tracking equipment. All C based. No problem. NXP processor. Not bad. MQX RTOS. Bloody night mare. (not an RTOS by the way) Had to drill down and re-write the drivers and part of the OS. The young buck in charge! did not like my style of programming. I did not like his. (macro use every where) Who cares if your style is not liked by someone else. does the end result work? Can someone else follow the code you have produced? If so then job done. Am fed up with programmers trying to copy someone else's style and spending months making it look pretty instead of making a product work using their own style. (if possible) STOP copying and pasting. Without understanding that which you are copying. Anyway. The message is. Develop your own style and progress with that. Ken.
That seems sensible, with a heavy caveat. Public APIs with a general/public development audience (meaning beyond your company/team) Like if you're making libraries or components. At that point, I think it's important to adopt as widely available/common denominator standard as possible for the public facing APIs at least. This makes everyone's lives easier, except maybe yours (or mine) due to the research and learning curve, but in the end it saves user headache and in some cases can cut some of the tech documentation down a bit because you don't have to re-explain basic concepts, like say, a dictionary object. If you're using those to enumerate keyed items you don't need to document an "IndexedCollection" class or whatever. So in general i agree, but again public facing APIs are my sticking point. I'll die on that hill.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
:) Seriously though, when you get older you live and let live. Truths become less absolute.
I agree with that. In most aspects of my life I am very buddhist. In most of my coding I am. Public facing APIs are a hill I'll die on though. And by public facing, I meant interfaces that are intended to be consumed by a wider audience than one's company/team Standards here are sooo important, for reasons I could practically write a book on.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.