The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
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.
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)
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.
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.
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.
The only strong conviction I have related to coding styles is when changing someone else's code.
It is expressed by:
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.
I need to stop reading these threads before coffee.
"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.
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.
Some companies put code through a pretty-printer as part of the check-in process. You could try that. But you have to be the first developer...
Boy...constants on the left...I haven't seen that in awhile.
I've been accused of having an "idiosyncratic" coding style because I like to add spaces to visually line up parts of my C++ class definitions. I don't worry about it. It's my practice, and I do what I want. If someone wants to change it, they can. If the coding standard actually says not to do it, then I don't.
Speaking of which, I once had a colleague edit my C++ code to change all the C++-style // comments into C-style /*...*/ comments. If you're reading this, "Whatever, dude."
My own experience was 1 year of working with very strict coding style guidelines, out of many years where things are much more laissez faire. Literally hundreds of formal rules, plus as many unstated informal one that everyone was supposed to know. Code reviews ended up being a bitch fest where 90% of the argy bargy was about code style. It literally slowed productivity and momentum to a crawl.
On all my other team projects, productivity was much higher, and not necessarily any worse technical debt-wise. Code reviews were simpler and much more productive/pleasant. There are some things one simply should not do (eg exception unsafe code, unnecessary pass-by-value) - everything else, just let it go man. I got quite tolerant of Hungarian notation, for example, just ignoring it as white noise (as it effectively is). You can tell instantly who wrote a piece of code from its style, so any questions, you know who to ask, if they're still around.
Walking to the Station this morning, cut through a car park that was used by Junkies and delinquents.
Smashed Stella bottles, needles etc. council gets a grant, claim it's to clean up. No needles, a smashed wooden case and empty bottles of Merlot & Cabinet Savingon. it's not as bad but...
What's changed in my profile, I'm a head, not a Bob!