Coding Pet Peeves
-
1. I just can stand it when someone doesn't use braces in IF statements:
static void Main(string[] args)
{
bool isTrue = false;if (isTrue) Console.WriteLine("line1") ; Console.WriteLine("line2"); Console.WriteLine("line3"); Console.ReadLine();}
2. XAML where the code is all on one line! (This is all on one line!)
3. First brace not on a new line:
static void Main(string[] args)
{
bool isTrue = false;if (isTrue) { Console.WriteLine("line1"); } Console.WriteLine("line2"); Console.WriteLine("line3"); Console.ReadLine();}
What bugs you when you see someone else's code?
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
-
Clicked on the link, read what was said there and pondered for a minute. I've decided that is one of the dumber language decisions I've ever seen.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated. I’m begging you for the benefit of everyone, don’t be STUPID.
MarkTJohnson wrote:
Clicked on the link, read what was said there and pondered for a minute. I've decided that is one of the dumber language decisions I've ever seen.
Dumb decisions pretty much defines JavaScript. The only thing I can think of that JavaScript missed is use of indents to define blocks as in Python.
-
1. I just can stand it when someone doesn't use braces in IF statements:
static void Main(string[] args)
{
bool isTrue = false;if (isTrue) Console.WriteLine("line1") ; Console.WriteLine("line2"); Console.WriteLine("line3"); Console.ReadLine();}
2. XAML where the code is all on one line! (This is all on one line!)
3. First brace not on a new line:
static void Main(string[] args)
{
bool isTrue = false;if (isTrue) { Console.WriteLine("line1"); } Console.WriteLine("line2"); Console.WriteLine("line3"); Console.ReadLine();}
What bugs you when you see someone else's code?
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
It really annoys me when people don't respect the coding style they encounter while changing someone else's code. It's even worse when they run a reformatter that changes the entire file to their preferred style. I think a bunch of the style quirks like #3 came from a time where the number of lines in the file made navigation arduous. I'm looking at you ed.
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.
-
1. I just can stand it when someone doesn't use braces in IF statements:
static void Main(string[] args)
{
bool isTrue = false;if (isTrue) Console.WriteLine("line1") ; Console.WriteLine("line2"); Console.WriteLine("line3"); Console.ReadLine();}
2. XAML where the code is all on one line! (This is all on one line!)
3. First brace not on a new line:
static void Main(string[] args)
{
bool isTrue = false;if (isTrue) { Console.WriteLine("line1"); } Console.WriteLine("line2"); Console.WriteLine("line3"); Console.ReadLine();}
What bugs you when you see someone else's code?
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
-
#3 most definitely, #1 less so. Empty 'catch' blocks, ran into that fairly recently...:mad::mad::mad:
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
You would hate my use of On Error Resume Next. This implicitely sets the code as try { statement1 } catch {} try { statement2 } catch {} etc. There are some places where this construct is perfectly fine, but only in short modules. Oh, and I don't use the other On Error statements. Try Catch Finally is far better.
-
It really annoys me when people don't respect the coding style they encounter while changing someone else's code. It's even worse when they run a reformatter that changes the entire file to their preferred style. I think a bunch of the style quirks like #3 came from a time where the number of lines in the file made navigation arduous. I'm looking at you ed.
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.
MikeTheFid wrote:
I think a bunch of the style quirks like #3 came from a time where the number of lines in the file made navigation arduous. I'm looking at you ed.
Not sure if it's true or just an internet legend, but I've read that the opening brace on the previous line style first gained popularity when the layout person at the publisher for what became a very influential book made the change to reduce the page count.
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
-
1. I just can stand it when someone doesn't use braces in IF statements:
static void Main(string[] args)
{
bool isTrue = false;if (isTrue) Console.WriteLine("line1") ; Console.WriteLine("line2"); Console.WriteLine("line3"); Console.ReadLine();}
2. XAML where the code is all on one line! (This is all on one line!)
3. First brace not on a new line:
static void Main(string[] args)
{
bool isTrue = false;if (isTrue) { Console.WriteLine("line1"); } Console.WriteLine("line2"); Console.WriteLine("line3"); Console.ReadLine();}
What bugs you when you see someone else's code?
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
return func_0(func_1(func_2(func_3())));i may have lost a job because during interview the coder showing me his code showed me code like this and i told him i thought it was terrible . probably a good thing i didn't get it . there was a lit cigarette dangling from his mouth and i hate cigarettes . -
1. I just can stand it when someone doesn't use braces in IF statements:
static void Main(string[] args)
{
bool isTrue = false;if (isTrue) Console.WriteLine("line1") ; Console.WriteLine("line2"); Console.WriteLine("line3"); Console.ReadLine();}
2. XAML where the code is all on one line! (This is all on one line!)
3. First brace not on a new line:
static void Main(string[] args)
{
bool isTrue = false;if (isTrue) { Console.WriteLine("line1"); } Console.WriteLine("line2"); Console.WriteLine("line3"); Console.ReadLine();}
What bugs you when you see someone else's code?
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
Kevin Marois wrote:
What bugs you when you see someone else's code?
What bugs me is when someone insists their coding style is 'better' and thus makes it a formal coding standard for the company. Having spent more than than a decade neck deep in formal process standards including studying actual formal research I know that coding style guides have zero measurable impact on any objective quality metric. The most common refrain is that it is more 'readable'. I spent quite a bit of time trying to find any research at all that actually objectively measured that. I found one single study which was based on marketing material (not code) which only showed that more than 4 type faces was not a good idea.
-
MarkTJohnson wrote:
I've decided that is one of the dumber language decisions I've ever seen.
People that dismiss JavaScript really just don't know it. Yes, it started off quickly/rushed, but it's come a long way. It's different. It's both functional and OOP. Nothing more. Nothing less. I think it's a great language, minus a few little quirks... which most languages have. It started off being web centric, so it has historic "issues" from that like ASI. Most web languages are script kiddie friendly, but JavaScript/ECMAScript has come a long, long way. I can promise you that most issues with the language is more so due to it being popular and 99% of people really knowing nothing about it. Not to mention, it's fast. Really fast, thanks to the optimizations over the years. Of course, not Rust/C++/C# fast... but it's one of the fastest scripting languages out there.
Jeremy Falcon
-
Use of literal values annoys me a lot. Especially when that hard-coded value needs to be changed.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
It's not exactly code, but comment boxes in the form of complete rectangles. The pinheads who originally drew them presumably believed that other people adding comments in the box would bother to keep its right-hand border nicely aligned. Not to mention that many of those comments provided a revision history for even the most trivial changes when, even in 1981, we had a source code management system that provided a full history, so that you could see who made each change, why, and get a diff between whichever versions you wanted.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Greg Utas wrote:
The pinheads who originally drew them presumably
Well to be fair I wasn't a pinhead when I did that very long ago. Just inexperienced.
Greg Utas wrote:
most trivial changes when, even in 1981, we had a source code management system that provided a full history
There are two comments for that one. One it is just so cool the first time one figures out source control macros. Who can't resist using the one that inserts the change history? Two been a while but it was after the year 2000 when a company I interviewed for, when I asked what source control system they were using, the interviewer explained that they had been considering putting one of those in place so my experience would fit well with that.
-
It really annoys me when people don't respect the coding style they encounter while changing someone else's code. It's even worse when they run a reformatter that changes the entire file to their preferred style. I think a bunch of the style quirks like #3 came from a time where the number of lines in the file made navigation arduous. I'm looking at you ed.
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.
-
1. I just can stand it when someone doesn't use braces in IF statements:
static void Main(string[] args)
{
bool isTrue = false;if (isTrue) Console.WriteLine("line1") ; Console.WriteLine("line2"); Console.WriteLine("line3"); Console.ReadLine();}
2. XAML where the code is all on one line! (This is all on one line!)
3. First brace not on a new line:
static void Main(string[] args)
{
bool isTrue = false;if (isTrue) { Console.WriteLine("line1"); } Console.WriteLine("line2"); Console.WriteLine("line3"); Console.ReadLine();}
What bugs you when you see someone else's code?
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
Took me a while to figure out the first one was legal C. It's also a pet peeve of mine. But after years of seeing and understanding the most elegant hacks and algorithms (and then a lot of the asm keyword)...you resign yourself to knowing K&R syntax is optional. Readability being a pipe dream (since in my field, thinking like the computer is the highest form of enlightenment for an engineer)
-
Rick York wrote:
Especially when that hard-coded value needs to be changed.
All code will need to change. That is just a fact of life. But coding for all possible futures just leads to code that is hard to understand and maintain in all futures.
-
1. I just can stand it when someone doesn't use braces in IF statements:
static void Main(string[] args)
{
bool isTrue = false;if (isTrue) Console.WriteLine("line1") ; Console.WriteLine("line2"); Console.WriteLine("line3"); Console.ReadLine();}
2. XAML where the code is all on one line! (This is all on one line!)
3. First brace not on a new line:
static void Main(string[] args)
{
bool isTrue = false;if (isTrue) { Console.WriteLine("line1"); } Console.WriteLine("line2"); Console.WriteLine("line3"); Console.ReadLine();}
What bugs you when you see someone else's code?
In theory, theory and practice are the same. But in practice, they never are.” If it's not broken, fix it until it is. Everything makes sense in someone's mind.
I shall disagree on #3 because I prefer exactly the opposite. Apart from that, pretty much only poorly written code annoys me. I clearly remember the time I've been maintaining someone else's code just to read the following statement (methods and variable names have been changed to preserve the code, although kept the language):
class TReport1 : TReport
private
shouldPrint: boolean;
// ...
end;// ...
procedure TReport1.Label1Print(var print: boolean);
begin
if shouldPrint = true then
print = true;
else
print = false;
end;I swear that it was exactly like this. All over the code, repeated a thousand time for each element on the report (yes, the person didn't even reuse the same method). And there was nothing else, nothing to control or change the value of
shouldPrint. I was tempted to rewrite it all but time and the rule of not messing with what is working prevented me. I still have nightmares with this code...- Leonardo
-
Kevin Marois wrote:
What bugs you when you see someone else's code?
What bugs me is when someone insists their coding style is 'better' and thus makes it a formal coding standard for the company. Having spent more than than a decade neck deep in formal process standards including studying actual formal research I know that coding style guides have zero measurable impact on any objective quality metric. The most common refrain is that it is more 'readable'. I spent quite a bit of time trying to find any research at all that actually objectively measured that. I found one single study which was based on marketing material (not code) which only showed that more than 4 type faces was not a good idea.
I also used to think like this, but my current job has taught me why one should have and follow a corporate style guide: versioning. If everyone uses linting to format code to their style after changing a single line on a file, version systems will register thousands of changes on a file and hide what has really been altered on the code. I never question this anymore but follow my own standards for my personal projects.
- Leonardo
-
I also used to think like this, but my current job has taught me why one should have and follow a corporate style guide: versioning. If everyone uses linting to format code to their style after changing a single line on a file, version systems will register thousands of changes on a file and hide what has really been altered on the code. I never question this anymore but follow my own standards for my personal projects.
- Leonardo
Leonardo Pessoa wrote:
If everyone uses linting to format code to their style after changing a single line on a file
Correct. And I agree that is a problem for exactly the same reason (even posted that in this thread on another message.) But a formal style guide doesn't really have anything to do with that practice.
-
Use of literal values annoys me a lot. Especially when that hard-coded value needs to be changed.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
Rick York wrote:
Use of literal values annoys me a lot. Especially when that hard-coded value needs to be changed.
Only if the literal value is a parameter that can potentially have different values. Too often I've seen things that are as silly as static const int two=2; static const string emptyString=""; or maybe static const string fooBar="fooBar"; So there are limits to when replacing hard coded values by identifiers is a good idea.
-
People who go against the editor's defaults X| I'm currently working on a project where the developer uses two spaces instead of the default four. So now, whenever I change a file and I save it, Visual Studio reformats the entire file to have four spaces. We're now working with editorconfig files... Same for curly braces on the same line, seen it before and Visual Studio just keeps trying to correct me. At one time I've even seen a project where curly braces and semi-colons were always aligned to the end of a line, like on column 800 or something :~ How the :elephant: does someone think "let's mess up the VS settings before starting to write code!" and then go all out of his way to have such an unnatural coding style X|
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
