Aspyr Media have delayed the Civilization VI 'Fall 2017' update until sometime after the 'holiday break'

Quoting: tuubi

Quoting: slaapliedjeWhat are your thoughts on that?

Whether your code is readable or not, comments are a must. What you consider readable might be total gibberish to someone else. Readability of a function or other code structure is also often dependent on context.

I'm sure anyone who's ever had to work on someone else's code would agree.

Ha, thank you, because that's exactly what I've said as well as all other programmers I've talked to. The manager of that team was... well special. One of the many things he'd done was modify the xml for a tomcat machine on a production server to create a new instance, and he copied one part, and left the port number the same as the default instance, so it took down the production system.

Also didn't understand how patch files work and just copy/pasted the patch file directly into the code, + / - and all!

Quoting: GuestI can vouch for the necessity of code comments. Why things are done this way, or not that way, and what certain black magic code actually does. The latter almost always have more comments than code, just to explain it.
Doesn't mean code is unreadable of course. Proper interfaces hide a lot of the more intricate incantations, keeping overall design from plunging into insanity.
Especially with larger teams, good comments and documentation (and they can often be one & the same thanks to tools like doxygen) are an absolute must.

I have worked on large teams, small teams, and now I am working independently. Useful comments are helpful regardless of team size.

Also, yes proper interfaces (and functions) can also be useful in reducing overall code complexity. When you put the most complex code behind this, you make it so that the complex code only needs to be modified when absolutely necessary; which in turn helps avoid creating bugs.

It just... there is this book called Clean Code. It became influential because it had good advices. And guy there says if the code is good, it doesn't need comments and that comments are sign of bad code that isn't readable.

And a lot of people adopted this approach.

Quoting: ColomboIt just... there is this book called Clean Code. It became influential because it had good advices. And guy there says if the code is good, it doesn't need comments and that comments are sign of bad code that isn't readable.

And a lot of people adopted this approach.

Colombo, you already rebuked this approach with your earlier comment:

Quoting: ColomboOften, what is important is not comment what function does. You can see it if the code is well written. More important is to know why the code does a certain thing.

With clean code, yes, it should be easy to know what something does... but reading code alone does not and can not tell you why it was done a particular way.

Personally, I also like to add tidbits of other areas of the codebase that should be looked at if something changes because it may be affected or tightly integrated with the logic in the area I am currently changing.

I also use comments to keep track of changes to the code. While I do use source control, when I am digging through code I don't always check the date of every file to see when it was last changed. Those quick comments at the top save me a lot of time.

While good naming conventions can tell you the source of where variables are coming from, I will use comments if I need to go a little further.

An extra 5 or 10 minutes of creating comments when I write some code can save me hours later, in 6 months from now when I need to modify code or when I am hunting for bugs.

For the record, some comments are useless:
print(variable_name); // writes the variable to the screen
that is pretty obvious and useless.

However...
safe_print(variable_name); // variable_name contains special characters and needs to have the output sanitized
That can be quite useful and save time and heartaches later.

I can not agree with this philosophy of code not needing comments. IMHO, that is horrible advice. I doubt anyone who believes in it has ever written code with any real complexity. They surely have not gone back to old code six months later, (or someone else's code) and tried to figure out why something is happening.

I suspect that many like the advice of not creating comments because they are too lazy to do it in the first place and are not advanced enough to recognize the significance.

I am a damn good developer. With that knowledge, I realize that I still make mistakes. I want to ensure that when I go back and look for those mistakes that I have every tool available to me to help find them in the quickest way. Comments help... a lot.

QuoteColombo, you already rebuked this approach with your earlier comment:

I was merely stating how this trend began.

For an example, see here:
http://apdevblog.com/comments-in-code/

Quoting: Guest

Quoting: slaapliedjeThat said, at my previous job, the developers there were always told that if their code was too complex that people couldn't just look at it and it needed a comment to say what the code did, then they were doing it wrong, and they were chastised for using comments at all.

I think that's idiotic, because some complex functions need to be... well complex enough that a comment should be used. What are your thoughts on that?

I can bet any money that policy was made by some fucking moronic manager, who has never written a line of code in his life, but has read all the books on Scrum and Agile, and all these other bullshit methodologies.

If he'd said that to me, I'd have punched him in the face, and then promptly handed in my notice.

Ha! Even as someone not on his team and having to deal with him, I wanted to punch him in the face and hand in my notice.

True Story: Same guy, always complained there was an echo and the sound cutting out on his VOIP phone. I told him to turn down the volume on his speaker phone a couple of notches, because the placement of the speaker and the microphone would cause the sound to reverb off the desk and with SIP being the way it is, it would try to auto-correct the noise, causing drops in audio and an echo. Finally Aastra released a firmware update that literally maxed out the volume at a firmware level. Every time I'd lower the volume, he'd raise it back up, causing the problem.

His comment when Aastra released the firmware, "About time you fixed it." I about stabbed him. Here's the fun part. Who in their right mind talks to clients on a speaker phone!? All the managers did that, they'd leave their office door open and talk to clients on speaker phones... drove me nuts.

I should write a blog for how much crazy shit went on there...

Quoting: stretch611I can not agree with this philosophy of code not needing comments. IMHO, that is horrible advice. I doubt anyone who believes in it has ever written code with any real complexity. They surely have not gone back to old code six months later, (or someone else's code) and tried to figure out why something is happening.

I suspect that many like the advice of not creating comments because they are too lazy to do it in the first place and are not advanced enough to recognize the significance.

I am a damn good developer. With that knowledge, I realize that I still make mistakes. I want to ensure that when I go back and look for those mistakes that I have every tool available to me to help find them in the quickest way. Comments help... a lot.

Well, I have seen the opposite too: a developer write the initial code and uses a fair among of rather simple comments. A second developer touches the code (years) later, does some refactoring but leaves the (no longer matching) comments as is, cause it seems nice to have comments and because comments aren't touched if you use some tooling for refactoring (Jetbrains and friends). A third developer has to work on the code later again and gets utterly confused cause the comments are sending him into a completely false direction. All sort of comments are fine if you are the only developer of a piece of code, even over time. Though comments can have side effects if the team changes over time.

In my opinion comments should be used to explain assumptions, algorithm or describe a public api. Most basic comments though should rather move into variable name, method extraction and methods names etc. One of the important rules in software engineering imho: You never write code for yourself, but for your team members.

Quoting: jensA second developer touches the code (years) later, does some refactoring but leaves the (no longer matching) comments as is, cause it seems nice to have comments and because comments aren't touched if you use some tooling for refactoring (Jetbrains and friends).

And here you see a developer who doesn't do his/her job. If comments are no longer relevant after you've changed the code, it's your job to update or remove them accordingly. Tooling is a bad excuse.

Quoting: tuubi

Quoting: jensA second developer touches the code (years) later, does some refactoring but leaves the (no longer matching) comments as is, cause it seems nice to have comments and because comments aren't touched if you use some tooling for refactoring (Jetbrains and friends).

And here you see a developer who doesn't do his/her job. If comments are no longer relevant after you've changed the code, it's your job to update or remove them accordingly. Tooling is a bad excuse.

Welcome to the real world ;). Of course this was a bad job, but these things do happen, though usually much more gradually over time thus a lot less obvious.

Quoting: jens

Quoting: tuubi

Quoting: jensA second developer touches the code (years) later, does some refactoring but leaves the (no longer matching) comments as is, cause it seems nice to have comments and because comments aren't touched if you use some tooling for refactoring (Jetbrains and friends).

And here you see a developer who doesn't do his/her job. If comments are no longer relevant after you've changed the code, it's your job to update or remove them accordingly. Tooling is a bad excuse.

Welcome to the real world ;). Of course this was a bad job, but these things do happen, though usually much more gradually over time thus a lot less obvious.

Ignoring the condescending tone of your reply, is that supposed to be an argument against code comments? If a team member messes things up, you might need tighter project control and/or coding guidelines. Otherwise that particular developer's sloppiness is bound to cause problems for the rest of the team. A bit of misinformation in comments might soon be the least of your worries.

Sorry if I fail to find the humour in this, but I have enough experience of running team projects for this to strike a nerve.