Intervention: Coding Guidelines
-
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.
-
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.
Well, do you think any API became unusable because of the style of its interface?
-
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.
The point I was trying to make is. Do not loose heart if someone does not like your style. Everyone has their own style. So long as others can follow your code, does it matter. As a programmer (if you view it as I) you will try to make it as efficient as possible. (think and re-write, think and re-write) Keep a problem area in the back of your mind, it may be working, but you know there is a possible problem there. Do not! copy someone else's style. (this is for the new comers) Make mistakes. Admit it and fix them. A programming style cannot be learnt from a book. I love using multi dimensional arrays. They are efficient, but the code is really hard to follow. Therefore, I have to write a document explaining exactly how the code works. Rambling, I know. Ken.
-
Well, do you think any API became unusable because of the style of its interface?
I think what happens is people get less inclined to use it as the learning curve grows. Especially with the rate people are expected to learn technologies. The more one-off your style is, the more difficult to adapt to it. Furthermore, when integrating many components it makes the glue code clunky if the APIs don't even remotely match up to each other in terms of how they're named and how you navigate them. Pretty soon everything is spaghetti. Glue has always been glue code, and somewhat messy, but how messy largely depends on how standardized everything is in terms of how it's programmed against. It's hard to put a point on specifically, if only because so many APIs with a one-off style suffer from other problems (libutp is a good example) but problematic APIs lead to less adopters. So if you want wider adoption and higher quality code it's a good idea to keep your public APIs playing nice and consistently with as much else as you can. This means in .NET for example, at least familiarizing oneself with microsoft style and standard guidelines. Why? because the 6500+ base classes in .NET are coded out that way, and people already know how to use them. So make your API similar and the learning curve is less steep - seems obvious to me but then i've been coding for a long time too - not quite 40 years like i guess some people here
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.
I used to have OCD some years ago and I overcame it by noticing that I have it, noticing what particular actions I'm doing due to OCD and realizing that those actions are nonsense that cost time, don't even bring enjoyment and that's about it. The rest was a tad of willpower and utilitarism.
-
The point I was trying to make is. Do not loose heart if someone does not like your style. Everyone has their own style. So long as others can follow your code, does it matter. As a programmer (if you view it as I) you will try to make it as efficient as possible. (think and re-write, think and re-write) Keep a problem area in the back of your mind, it may be working, but you know there is a possible problem there. Do not! copy someone else's style. (this is for the new comers) Make mistakes. Admit it and fix them. A programming style cannot be learnt from a book. I love using multi dimensional arrays. They are efficient, but the code is really hard to follow. Therefore, I have to write a document explaining exactly how the code works. Rambling, I know. Ken.
> I love using multi dimensional arrays. They are efficient, but the code is really hard to follow. In .NET they're inefficient. Nested arrays are more efficient. Weird, I know. But in .NET I end up creating really ugly structures for a similar reason as you using MD arrays (like in C or C++) Here's a recent datatype I had to munge through. Yes, I use comments for this
Tuple<TAccept, Tuple<KeyValuePair<char, char>[], int>[]>[]Fortunately, it's opaque to the end consumer. It's basically a "handle"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 used to have OCD some years ago and I overcame it by noticing that I have it, noticing what particular actions I'm doing due to OCD and realizing that those actions are nonsense that cost time, don't even bring enjoyment and that's about it. The rest was a tad of willpower and utilitarism.
Intellectually I understand that. In most areas of my life I can even apply it. Here I'm battling 30 years of NOT doing that (being mindful and letting go) where it comes to coding. Maybe I'm lacking in the willpower department. I usually find ways to hack around my lack of willpower. :laugh:
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.
-
Intellectually I understand that. In most areas of my life I can even apply it. Here I'm battling 30 years of NOT doing that (being mindful and letting go) where it comes to coding. Maybe I'm lacking in the willpower department. I usually find ways to hack around my lack of willpower. :laugh:
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.
How much of a hardliner utilitarist are you? I very much am and that helps a huge lot in overcoming nonsensical habits. I wouldn't even say that I'm big in the willpower department, but my utilitarism is a suitable substitute.
-
> I love using multi dimensional arrays. They are efficient, but the code is really hard to follow. In .NET they're inefficient. Nested arrays are more efficient. Weird, I know. But in .NET I end up creating really ugly structures for a similar reason as you using MD arrays (like in C or C++) Here's a recent datatype I had to munge through. Yes, I use comments for this
Tuple<TAccept, Tuple<KeyValuePair<char, char>[], int>[]>[]Fortunately, it's opaque to the end consumer. It's basically a "handle"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 do would not like to come across that in a piece of code.
-
Except for 1TB - that's ALWAYS wrong. :laugh:
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
Nothing should ever be camelCase. X|
Agreed. I don't like or use it myself, but we had a couple folks who liked it.
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.
If you are reviewing code, use your smart editor to format it the way you want so you can understand it. If you need to make a change after review, revert the file, make your change, test, move on. And follow this rule: Rule #1 for source control sanity retention: Never combine a reformat with an actual code change in the same commit! Use a separate commit with a "//reformat" comment as the first line for formatting, then remove the comment and do the real change.
-
your style sucks, so does mine, oh and that bloke over there: his style sucks too. each to their own. If style is an issue you've got a lot more growing up to do.
Message Signature (Click to edit ->)
All coding styles suck. But it's important that everyone in a project is using the same general style to keep the code readable. When available I prefer platform standards/IDE autoformat defaults. (And yes that means I use different brace placement styles in C# and Java.)
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
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.
The only strong conviction I have related to coding styles is when changing someone else's code. It is expressed by:
Quote:
When in Rome, do as the Romans do.
It annoys the elephant out of me when a source file has 4 different styles because people can't be bothered to conform to what's there or are so stubborn they want to impose their style on everyone else, or they simply don't give an elephant about anyone else. /endRant I need to stop reading these threads before coffee.
Cheers, Mike Fidler "I intend to live forever - so far, so good." Steven Wright "I almost had a psychic girlfriend but she left me before we met." Also Steven Wright "I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
-
How much of a hardliner utilitarist are you? I very much am and that helps a huge lot in overcoming nonsensical habits. I wouldn't even say that I'm big in the willpower department, but my utilitarism is a suitable substitute.
well i am an instrumentalist "what's real is what's useful" and by real, i mean what exists in any meaningful sense i am pretty much a hardliner about it maybe, if you'd consider that hardline.
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 do would not like to come across that in a piece of code.
me either. but it was either that or require a dependency in the generated output that i didn't need (it's part of a code generator)
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.
codewitch honey crisis wrote:
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
There's an easy cure for this.. work on a project with a lot of devs that has a too-tight schedule and do as you want (i.e. shamelessly refactor all their code to your liking) until you wake up one day and realize that you're the one that needs to be duct taped to their chair so the product can ship on schedule. Ok, I'm half serious about that answer. The real answer is that you need to realize you can't do everybody else's job for them, and accept that, while they won't do things the way you would, the things will get done well enough to not matter.
I live in Oregon, and I'm an engineer.
