Your worthless opinion on how bits of code should be written

Your worthless opinion on how bits of code should be written.

Attached: 1547309047520.jpg (720x602, 71K)

Avoid high indentation levels. Emphasize expected path of execution by having it on the same flat indentation level. Don't comment the obvious stuff. Don't use exceptions. Goto is OK. Expect the reader to know the language.

Use
> if( something )
To separate logic from data

When writing example code, always add comments regardless of how trivial it is

Stop spouting bullshit and follow the damn train, CJ.

Everything should be made as simple to read as possible, and almost every function called that isn't something basic like a mathematic operation or something basic like an if/for/switch case should be commented.

>When writing example code, always add comments regardless of how trivial it is
plague

>If you have to think about it for more than a moment, comment it
>If you have to test it by hand, write a unit test
>If other people are going to use it, document it
>Keep your commit history organized
>Keep code modular
Had to leave my last company because they kept hiring interns who couldn't wrap their head around the idea that they had to test and document.

Use consistent naming and indentation.
Don't comment the syntax, comment the purpose.
Don't do more than 3 levels of indentation.
Don't do more than 3 levels of hierarchy.
Decouple your objects(sorry, fp-fags, objects are more reusable than functions)
Use objects only to encapsulate side effects.
Don't use DSLs, it's write-only code.

Make functions small so you can easily test them without mocking out the entire os

what the fuck lmao

EXAMPLE is the keyword

Don't write comments to explain what the code does, unless it's really, really complex (which it usually shouldn't be) or a library for public use. Someone almost certainly will change the code without changing the comment. Instead comment on why you do something (if it's not obvious), those comments are so much more valuable.
It's good to make lots of short functions which are called only once. The compiler will likely inline them anyway, and the code will be 100x more readable and testable.
Using functional style with OOP is great for data processing and you should see what your language offers (e.g. Java streams, C# LINQ etc.) if you hadn't already done this.
If you use C++ and ever use the keywords new and delete, except for very rare cases, it means you don't know how to use C++.

>Someone almost certainly will change the code without changing the comment
No one on my team is going to change code without looking at the surrounding code, or they're getting kicked off. There's also no way that's getting past code review.

/thread

Surrounding code has nothing to do with this. Code often needs to be changed, and having a comment explain what this code does requires you to update the comment as well. Some changes are minor, and the comment may not be updated, and it will be slightly wrong. No reason to have this comment when you can just read the code. Unless the code is so bad.

>Surrounding code has nothing to do with this.
Surrounding area, then.

I am not saying you should have tons of pointless comments everywhere. What I am saying is, whether it is a bad comment or not, there is no excuse to update the code without updating the comment.

>Look at area surrounding the code you're changing to verify correctness
>See comment
>Try to understand comment to see if you're breaking anything
>Update/remove comment if necessary

There's no reason not to do that. Either you didn't try to check or didn't understand the impact of your code change.

>Some changes are minor
No change is minor enough to not understand the impact it has on the surrounding code. I have seen single character changes or changes that "shouldn't have any side effects" bring down applications in production.

A comment that says what code does doesn't add anything to understanding the impact of changing it. Actually it doesn't add anything of value at all. Whenever I see a comment like this, I remove it.
On the other hand, if the comment explained why something was done this way, it would be valuable and help with understanding the impact of changing the code.

I agree with you, retard. I'm just saying there's never an excuse not to update a comment.

>he needs more bits to write the same function

code should not be written in a sexist manner.

These things often happen by accident, even with code review. That's why in general, you always want to avoid things that need to be changed in more than one place, if possible.