Slashdot Mirror
Ask Slashdot: When Do You Include 'Unnecessary' Code? (sas.com)
"For more than 20 years I've been putting semicolons at the end of programming statements in SAS, C/C++, and Java/Javascript," writes Rick Wicklin, a researcher in computational statistics at SAS. "But lately I've been working in a computer language that does not require semicolons. Nevertheless... I catch myself typing unnecessary semicolons out of habit," he writes, while at other times "I include optional statements in my programs for clarity, readability, or to practice defensive programming." While Wicklin's post is geared towards SAS programming, Slashdot reader theodp writes that the question is a language-agnostic one:
...when to include technically-unnecessary code -- e.g., variable declarations, superfluous punctuation, block constructs for single statements, values for optional parameters that are the defaults, debugging/validation statements, non-critical error handling, explicitly destroying objects that would otherwise be deleted on exit, labeled NEXT statements, full qualification of objects/methods, unneeded code from templates...
He's wondering if other Slashdot readers have trouble tolerating their co-workers' unnecessary codes choices (which he demonstrates with a video clip from Silicon Valley). So leave your answers in the comments. When do you do include 'unnecessary' code in your programs -- and why?
He's wondering if other Slashdot readers have trouble tolerating their co-workers' unnecessary codes choices (which he demonstrates with a video clip from Silicon Valley). So leave your answers in the comments. When do you do include 'unnecessary' code in your programs -- and why?
All of my code is unnecessary, you insensitive clod!
I'll add extra intermediate variables, break up lines to make them as short as possible, and use extra verbose variable names along with explanatory comments of the logic of each object/function. The goal is to make it so that anyone reading the class for the first time with no prior experience can understand its purpose and basic function without having to spend 5 minutes deobfuscating the code. Yes you generally can golf most any class into a single line, but it's unmaintainable even to its original creator after a couple weeks.
That said, for personal consumption code, I don't generally bother going to that much effort to make my code clean/clear.
.
There are some programmers who like to complain about other people's code (it seems to make them think they are a better coder), so why not give them something intended for them to complain about?
... so debugging/validation statements and error handling can be removed.
Some others are a cheap way not to write comments.
Others are... noise... that might cause bugs as soon as the function is modified.
ID: the nose did not occur naturally, how would we wear glasses otherwise? (apologies to Voltaire)
In effect most punctuation, indented blocks etc is superfluous to a computer. Is your code more or less readable with whatever construct you include? What if you add more code between eg your declaration and your use, would it still be obvious?
That's why languages without those construct are a pain to work with, you add a bunch of code and suddenly you've lost whether you're 4 or 5 tabs deep when the tabulation decreases. I like to add comments to the end brackets of regular code myself and add brackets to all if statements. It's superfluous but it's harder to rewrite a conditional one liner into a multiline code after the fact.
Custom electronics and digital signage for your business: www.evcircuits.com
When Do You Include 'Unnecessary' Code?
Here is how I make the determination: if it reduces my cognitive burden now, later when I return to the same code, or other programmers who will have to maintain it, then I include it
These days, a programmers time is nearly always far and away the most expensive commodity employed in any project. Why should I spend time asking myself about minutiae rather than focusing on architecture and algorithms?
Not terminating statements with a semicolon means you're using semantic whitespace. Semantic whitespace is stupid. And the proper whitespace style is "tabs to indent, spaces to align". It's a courtesy to people who favor other tab widths.
If I think it makes the code looks cluttered I will remove it.
If I think it makes things more clear then I will put it in.
For instance, braces for if else where one of the branches is more than 1 line and the other isn't.
I never use variable names of more than one character unless all possible single character names have already been used, which rarely happens. I never indent blocks; extra white space is only superfluous. I never do in six lines of code what can be done in one long convoluted line. If the person that needs to maintain my code can't make sense of it, too bad. They're probably just a sloppy programmer.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
I used to make firmware that goes into aircraft instruments. The FAA has some guidelines on this.
Unnecessary code is generated machine code, and the rule is that you can have none of it. Source code doesn't matter, if it's ifdef'd out it's the same as commentary.
The theory is that if execution takes an unexpected jump, it can't land in anything that isn't specific to the purpose of the device. Some people take this to extremes, writing new versions of printf() that omit the floating point and pointer output formats when they're not used in the system.
However, if a buffer overflow causes the program to jump, it can't land in the middle of the pointer formatting section and send a pointer to the airspeed computer instead of the decimal altitude.
What the OP is talking about is unnecessary source, which is a different matter.
IBM did studies of bug frequency, and concluded that the number of bugs in a program depends on the number of source lines a programmer can see at any one moment. Big screens allow the programmer to view more lines of code at once, little screens require reading the code through a soda-straw.
Their studies showed that simple code-tightening techniques reduced the number of bugs. Placing the brace on the if-statement, for example, allows one more line to be viewed in the window. Omitting braces altogether for single-statement "if" saves another line. Using 120-char width lines instead of 80 allows fewer wrapped lines, and so on.
There is a competing goal of readability, so tightening can't be taken too far. The complex perl-style or APL-style "everything on a single line" construct goes the opposite direction - too much info and it becomes hard to understand at a glance.
Typical C-like syntax with line-tightening techniques is easy to read, and presents probably an optimal view of code to the engineer.
Braces on their own act like vertical whitespace. Requiring one-and-only-one exit from a subroutine leads to convoluted and chevron code (where the code looks like a big sideways "V" and the hints of indenting is lost). Requiring all definitions at the top of the module requires the reader to flip back-and-forth, and requiring Hungarian notation makes the code look like gobbledy-gook.
Dump it all.
Name your variables clearly, using nouns for objects and verbs for actions. Name your subroutines after their functions. Tighten your code to make it terse, but keep it readable.
In professional software development, the general idea is clear: if any non-functional change in a source code file makes it more readable and more maintainable, then it's good, and vice versa. You write the thing once and it has to be maintained for years. This is actually called code refactoring, which is part of several methodologies.
Code refactoring may mean either adding or deleting code. There ought to be a golden middle point somewhere where the code is neither too verbose nor too condensed.
There is a slight complication in that not every person agrees what is the most readable form for a program, but in general it's best to imagine that you may have a total autobiographical amnesia in the next day and still need to understand what the program does.
A function should read like a good short story. Set the scene, develop the characters, advance to the climax, then there's the denumont/ epilog (sp?) where loose ends get resolved. Add comments if the story is hard to follow, don't if it's not. If the story is too long, create some helper functions.
A dash of humor here and there helps keep things entertaining, but go easy on it.
Remember, some software archaeologist may have to go back in 5 or 10 years and figure out what the heck the code does to fix a problem -- and that guy may very well be you.
I'm completely serious. This is what I do, and I actually enjoy going back through my 10 year old code (I've got a nice stable job)
I've seen a lot of style wars - tabs vs spaces, braces starting same line vs next line vs omitted when possible, commented enums required (especially by European companies using StyleCop), etc.
All of that is unnecessary from a compiler perspective. But the style you are accustomed to aids your efficiency and effectiveness. Code doesn't care if it's consistently indented, but finding that unbalanced loop is much easier with it.
For me personally, since I'm in C++, Java, JavaScript/Node (never by choice), Groovy, C# and Python every week, style consistency for me, rather than optimizing for what zealots for a particular language want, is highly beneficial. So the Groovy gets semicolons. The inability of JavaScript to handle certain brace formattings resulted in me modifying my default across all the languages, because they other (real) languages don't care.
Use what makes you personally across all your development, and more importantly your entire team, faster and better.
I add "unnecessary" parentheses to complex expressions in order to avoid the mental burden of thinking of operator precedence. I instruct my team to do the same.
Obviously if I can name a sub expression reasonably I just extract it, this is often enough not a reasonable solution.
Usually I prefer terse code, but the above is a fairly common exception.
The items listed in the summary aren't unnecessary - they are good practices. Readability, ease of maintenance, debugging and error-handling are all good things, and SHOULD be included - even if they aren't needed in a specific instance.
Car analogy: Most cars never need to have airbags, but we put them in because they are a good idea. The same should go for the listed code constructs - they should be there for the times it does matter.
Reading code is like reading the dictionary - you have to read half of it before you can go back and understand it.
I over parenthesize C/C++ expressions. There are so many precedence levels that it is easy to forget who goes first**. There's a limit of course, I wouldn't write 4+(5*6) but I would certainly fully parenthesize:
x = 4*A|| B? C||D: E && F || G +3;
** Brian Kernighan admitted to having the table of precedence glued to his monitor, since he himself can't keep them straight.
true that. also semicolons are optional in javascript. for ordinary statements you can simply leave them out.
I also write notes to people, like this one, with the usual amount of English that isn't really necessary - like a quarter of the words in this sentence.
A certain amount of redundancy in communication is still around, though, yes, languages tend to drop and slur words over the centuries. Interestingly, military communications, where you'd think speed was very important, tend to be written quite formally, that is to say, with lots of that redundant English. Turns out that clarity is even more important than speed when lives are on the line!
I bet that your really important code that runs SCADA and other real-word systems has the most ponderous, overstated, tedious and obvious code of all. The same way that surgeons say, "Hand me the #3 rib spreader" rather than "Gimme that" while gesturing in a general direction.
Actually declaring and destroying your variables - stating what they are in clear, rather than by implication, and making clear when they are no longer needed - should be considered documentation for the programmers, even if the mechanism will perform identically without it.
Since I make a ton of money, and my boss is itching to fire me and replace me with a Syrian refugee who will work for cafeteria scraps, I make heavy use of 6-level deep macros and the C downto operator: while (i --> 0)
Intron: the portion of DNA which expresses nothing useful.
Caveat: I am retired. Programming was a major part of my career between 1995 and 2005 but I mostly do HTML/CSS these days, with only enough PHP to glue others' existing scripts together.
What I determined back in the day is that efficient coding is unnecessary for performance when the wetware BKAC would always be the primary limiter on speed. Since virtually all of my work was repurposing documents from old versions of Word, Excel, WordPerfect, Lotus1-2-3, and other outdated apps to newer standards (mostly early HTML), I did not have to worry about shaving off microseconds. The typing speed of the person selecting the raw data had more impact on performance than the programming. So I was much more concerned with whether I would be able to rewrite a handler for a Windows3.11 app to work on a Windows98 version, if that need arose.
So I worked mostly in Perl using the Tk graphic interface and Javascript front ends, which made rapid development and easy revisions to meet new criteria possible. I used explicit declarations, human-readable naming conventions, extra punctuation, and the long way around the barn whenever the shorter routes looked like they might cause head-scratching later on.
If I had been working in an environment where microseconds counted, I would have used a compiled language and a different approach.
My old-timer's advice to you young'uns: Look at the environment you are coding in and match your coding style to fit its shape. Eschew becoming the cleverest code monkey in the cube farm and focus instead on becoming wiser than all the others.
I code for thousands of mostly-unique commercial software products a year, using 8 languages (mostly C#), for many dozens of major customers, and lots of smaller ones.
Because of this, I have a huge chain of demands I keep track of, and methods of automation in order to collectively manage a constant flow of data requirements, and of course tracking issues both shared and common between these scenarios.
When I'm coding, I've got to code in a way that communicates these details to myself, consistent between all the languages I might have to touch for coding, scripting, database, reporting, and specialized languages a client may suddenly require.
Because of that, my code has to be a loose framework, a late-binding train station of logic, where demands may switch at any moment, and limitations imposed from other teams may similarly pop up.
My code is littered with multi-paragraph discussions of a technology I once had to interact with (customers often switch back), large sections of functions commented out rather than deleted, and other 'bad' practices just to give me landmarks and a 'flavor' of what a customer is occasionally interested in, amidst a never-ending avalanche of context switching between products and customers.
I've redesigned these several systems from the ground floor once (they used to only handle a small fraction of the work, using an antiquated language), and am working with a team to do a better design... but it's been very difficult for a team of perfectionists to understand how to react to an unlimited flow of changing requirements. Fortunately, the code itself has been quite usable, and they're using the same languages, but no system can really handle these demands truly consistently - I'd call it NP ridiculous. It's basically the "mythical man month" writ live, where I've got to do my work, and train a team whose work process may never really be able to do what I can do - definitely healthier long term, but can't help but result in some amazing process failures.
I actually would have made most of these design changes myself, but at the time, I was forbidden by management from making those choices, since I was doing my work directly at the production level - so it's actually a bit of a relief to see someone at least allowed to make some of the better choices.
In short (and yes, for this scenario, this is short), because I'm doing alone, for years, what a team of almost any size would struggle to approximate, as many of us seem to be doing, I've got no choice but to code how I need to in order to have a system that I can sanely maintain in an insane set of requirements. There's not really a choice in the matter, if your put in a position where "oh, we suddenly need this" exists as a live production task in a growing industry.
Ryan Fenton
I usually write all my C++ if statements, even if they contain just one statement, with curly brackets. I read somewhere it was better to do this, but I can't remember why.
It's a land mine. When you later add a second line to the conditionally executed section, you then need to notice the lack of braces and add them or you will not get the intended behaviour.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Maybe because you are a douche?
The sad thing is, some people probably do get paid by LOC.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
Write code in a way you'd like to read it, if you didn't write it and had to fix/extend it.
If you've been programming since the early 80's, you've probably had to go back to code you wrote 10+ years before on occasion.
If its written well, (haha) with good comments and variable/function names, you'll spend almost no time getting it to work again.
Clarity is key, avoiding writing code which makes debugging difficult, I often create a local var and pass it to a function when I could just put it in the function call. Why? Well, I can easily look at it in the debugger, the little extra effort of a local var gets optimized out anyway, and it makes debugging a LOT faster.
Some "unnecessary" code can be very necessary to improve human understanding of the code and maintainability. When I use it, that's why.
If you believe that code will help someone with understanding (yourself included) then it is necessary. It is needed to help with clarity. It may not be strictly required for the correctness of your program, but your goal should not be to express the correct solution as succinctly as possible. That approach leads to many other problems.
Occasionally I include solutions for problems which have not yet been uncovered. Those methods may not be called (dead code) and any kind of static analysis would report them as "unnecessary." If I make the decision that such code will help me, or help someone else, later then I believe it is totally necessary, and good to include. Worse-case is that it will be a good starting point for someone later, and they will throw it away and replace it with something better.
Never include unnecessary code. If there are incorrect implementations that you are replacing, remove the incorrect ones! Don't leave traps lying around for people to get caught in. Unexecuted code, or not succinct code, is not unnecessary. I constantly include semicolons, and brackets around one-line conditionals - those are defensive practices which are designed to prevent future problems, and aid in clarity.
This is why people are hiring you - to apply human intelligence and judgement to a problem. There are situations where doing not strictly necessary things is appropriate, and situations when doing not strictly necessary things is a waste of time. It's up to you to decide. Different actions are necessary for different metrics. One thing may be necessary for a correct solution, and another thing may be necessary to help someone else understand your correct solution. Everything should be useful (necessary?) under some kind of metric.
If it's just for myself or a personal project, little comments or extraneous stuff
If a junior programmer or someone I haven't worked with before will be using it in some fashion, I'll probably use more descriptive variable names, more comments, even formal comment blocks describing a given method/function, etc.
But regardless of who it's for, I always use proper indentation, consistent naming conventions, etc., just makes life easier all around.
As far as error handling, again, depends on the audience, if there's an end user product where it really matters, then absolutely have thorough handling; if it's an internal app used by the dev team, probably stick to handling critical errors for the most part.
'The unexamined life is not worth living' - Socrates
Since when are semicolons considered code?
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
I get paid by the line you insensitive clod
Redundant semicolons at the end of macro instantiations that have an embedded semicolon. Because code editors try to auto-indent the next line if it's not there. Both the extraneous semicolon and the auto-indent make me twitchy, but... other people's libraries. What can you do.
SAS = Semicolon After Semicolon
Old SAS joke
Any c++ programmer with more than 1 years experience will see this immediately and slap some braces around it. Thanks to modern IDEs and standard indentation (which the IDE will auto-correct) it's extremely unlikely anyone will make this mistake, or it will go unseen for very long.
I'd group this sort of 'error prevention' in the same category as putting the constant first in every if statement e.g.
if (1 == YouShouldHaveDoneThisTheOtherWay)
{
Whatever();
}
The people who make the mistakes that this shit prevents have no place working on code.
All those moments will be lost in time, like tears in rain.
And that is why almost every country in the world uses SI units instead of outdated imperial measurements, like the US.
All those moments will be lost in time, like tears in rain.
Occasionally I include solutions for problems which have not yet been uncovered. Those methods may not be called (dead code) and any kind of static analysis would report them as "unnecessary." If I make the decision that such code will help me, or help someone else, later then I believe it is totally necessary, and good to include. Worse-case is that it will be a good starting point for someone later, and they will throw it away and replace it with something better.
This is called YAGNI - You Ain't Going to Need It, and all it does is clutter code and make it harder to see what is truly needed vs what some programmer thought might be needed at some point in the future, if some things changed. Don't do it. Alternatively, place it in as scaffolding, but remove whatever elements aren't needed before you ship the code.
Never include unnecessary code
See above.
I constantly include semicolons, and brackets around one-line conditionals - those are defensive practices which are designed to prevent future problems, and aid in clarity.
No decent programmer needs these, and often they just clutter the code. Only put in the semicolons and brackets that are actually needed by the language.
I agree with the final statements, though not the ideas you expressed which would be actionable items by those statements.
All those moments will be lost in time, like tears in rain.
This may vary,if writing something that is intended to be read by novices or some funcition that in my understanding should be explained by more verbose code.
I try to write self commented code where I can , and I'm a believer in simple to to read functions instead of 'virtuoso'code that needs heavy comments
JC
> block constructs for single statements
This one bugs the snot out of me, especially when the braces don't line up.
Any c++ programmer with more than 1 years experience will see this immediately and slap some braces around it. Thanks to modern IDEs and standard indentation (which the IDE will auto-correct) it's extremely unlikely anyone will make this mistake, or it will go unseen for very long.
I'd group this sort of 'error prevention' in the same category as putting the constant first in every if statement e.g.
if (1 == YouShouldHaveDoneThisTheOtherWay)
{
Whatever();
}
The people who make the mistakes that this shit prevents have no place working on code.
You assume braces. BEGIN/END is less visually distinguished.
You assume only one person will touch the code.
Code for what might happen, not what your ego tells you you will get away with.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Code for what might happen, not what your ego tells you you will get away with.
Experience tells me what might happen is that code and projects are broken up based on the experience of the teams working those code bases. You don't ever let an advanced code base get taken over by an inexperienced team. You will always have an A team, a B team, and the other guys. What is right for the A team is not right for the B team or the other guys - and it goes down the line.
There is always going to be advanced projects in languages that most team members will shy away from or will be too damn hard for them to work with - that's totally fine. Your 'B' team is most likely the vast number of team members. The 'A' team are those members able to work at the highest level, whatever that is within your organisation. They will take care of the really awful projects that need kid gloves to keep working, and they will prefer doing that work - because they know that's where they are challenged.
'B' team is the bulk of most teams. Your arbitrary rules are probably quite OK for these guys. They might even be best for most of these guys. Following the rules won't really harm them, as they will create / maintain code bases that also follow those rules - that's most code. Only the 'A' team members need to worry about code that breaks these sort of rules, and...why.
If syntax is causing you issues, you are the other guys.
All those moments will be lost in time, like tears in rain.
Your style is admirable. Keep it up!
In the future, I would want to not be isolated from my friends in the Space Station.
Well as you post as AC we don't know which of ... cough cough ... "your posts" got modded down.
That teaches you a lession, doesn't it?
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
In all your wisdome you still made a mistake:
You formatted your braces wrong!
Sorry to point that out!
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I often have to go in fix problems caused by people's overconfidence. Everyone is fallible.
I design chips, where the tolerance of design errors is substantially lower than for software. You can't just roll out a patch.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Code is for humans.
Extra code/white space usually means extra clarity.
And most compilers will either remove unreferenced unused code or the code will only execute once anyway so there's no real performance hit.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
Overcoding > Undercoding
Gain increased readability and clarity of actions involved, with little bloat cost. Bloat and inefficiency are from reckless calls and libraries and imports and poor design, often a result of lazy/inept design.
lol who cares phones have 4GB RAM anyway who cares the web container can run 16GB anyway, if the user doesn't have that much how is that my problem get an i7 faggots stop living in 2014.
I put in semicolons, curly braces, line breaks, and indentation if they make the code more maintainable and clearer to the human reader. For example Microsoft T/SQL doesn't need semicolons at the end of SQL statements, but I put them in anyway.
Obviously this is off topic for a story on comments in code.
I write a lot of embedded systems code, and everyone wonders why I check a timer configuration register that was already set at boot, or do an internal sanity check to verify everything is as I intended it to be before loading the timer (turning the output on) and then double check that the timer expired when I thought it should.
Sooner or later someone reuses the code, ignores the comments and takes those checks out. Then you get the "randomly quits working until I reboot" hell that drives warranty and service crazy!
How about "unnecessary language?"
> Never include unnecessary code. If there are incorrect implementations that you are replacing, remove the incorrect ones!
When possible, I comment them out with "wrapper" comments to preserve the code in the source control change history. And explain _why_ you've replaced the code, so the evidence is there for at least one or two more releases. It can be very difficult indeed to compare new code to the deleted code it replaces if you've successfully removed the visible traces of the deleted code.
Code should be rid of any fluff. Any description of what/how/why about the code should be in comments - well written and this is for human consumption; so it can be elaborate to avoid any misunderstanding. Code is written once but read/debugged many many times; Maintenance is the real cost. So you don't want to have noise in the code which takes a higher cognitive-load on your brain; your visual system too processes extra lines. These are unnecessary. Only after reading the code and thinking about it, you realize that code is harmless/unnecessary (eg while debugging or extending the software). The point is a line of code should have the least labor (cognitive/visual) from the human. A code which doesn't exist does this job the most perfectly. Hence write compact code; use standard libraries. Think at higher level of abstraction (like say containers instead of managing an array of objects); this needs spending lot more time in the design phase -- seeing the big picture of the various moving parts.
Strictly speaking, things like talking variable names aren't "necessary", the code will compile just find if you rename "error_flag", "sample_index" and "accu64" to "joe", "bob" and "alice".
Yes, code for the next person to work on it. And pray your predecessor did the same.
Personally I think of the described semicolons as 1 character comments.
And unneeded parenthesis in an expression are 2 character comments.
It look better if the comment describes the actual effect that calling the function would have, plus what each argument means.
AC:"The goal is to make it so that anyone reading the class for the first time
with no prior experience can understand its purpose and basic function
without having to spend 5 minutes deobfuscating the code.That said, for
personal consumption code, I don't generally bother going to that much effort
to make my code clean/clear.
----
and ^^ That said, I do the same for my personal code -- since maybe 10-15 years back when I started seeing code that I'd written 2-5 years before that I knew I had written, but looked totally foreign to me. As time has gone on and I write code that builds on code that builds on more code (much going into libs), AND as I am forced by ever changing priorities to work on more projects in "parallel" (meaning I have more projects that have unfinished code waiting for more attention), I find that even spending a few months away from some code and I realize I didn't leave myself enough signposts to spend 'no-time' getting back up to speed.
The 2nd big point of this discussion is who decides what is "unnecessary" and what removal of "extra code" doesn't violate the premise that premature optimization is, at least, in the top 5 time-wasters category? I had a Dilbertian-boss, who only wanted bugs fixed that were reported by paying customers, and didn't want pre-release stress testing on multi-threaded kernel code ("Today's untested code can become tomorrow's paycheck."), but using short-term solutions for short-term OS-limitations was bad -- especially if documented. I.e. estimated time before limitation was removed: 2-3 years (was actually 18 months). Condition necessary to hit the "design-flaw": 25-30 years of continuous system *uptime* (no reboots or crashes). Admittedly this wasn't windows, but ...
Of course, things got a lot easier once I switched from C to C++ and the STL and RAII idiom, but trying to release resources is still ingrained in my muscle memory; it takes a conscious effort in C++ NOT to explicitly release a resource acquired through initialization.
cpghost at Cordula's Web.
I say faux video as it shows two actors supposedly coding on identical macbooks.
Tabs vs spaces.... gad, I remember an editor that came with a "C" package that would always change any tab character into five spaces unless you designated the tab character to be an ANSI code insertion which took as many keystrokes as doing five space characters.
"Unnecessary Code" that is punctuation and comment for clarity is only "unnecessary" for scripts instead of programs. Programs are "compiled" which ignores comments and extra punctuation. So, the extra comments and punctuation only exists in the source code and is often beneficial for clarity. Try going back to an assembler program you wrote a decade before and try to remember what you did and why you did it that way. Or, worse yet, get assigned to update someone's code that retired a decade ago.
Do they still teach the difference in a compiler, an interpreter, and a scripter? So much pop literature doesn't seem to know the difference in a program and a script.
NRRPT/RCT
Code relating to a complex situation or unique idea can often be more understandable (and self-documenting) if laid out in a certain, sometimes more verbose, way
About accidental semi-colons, I was wondering about this one
if (1 == YouShouldHaveDoneThisTheOtherWay);
{
Whatever();
}