4 years in software engineering and that's what I have learned.

[coppice]

But, let me understand would you use the last offensive term you recently use in the other topic and call people "dumb moron" for this?

If you as sloppy in your software development as you were in editing your message in that thread, you definitely deserve the term. We all edit messages quickly, and make mistakes. However, if you are going to insult someone you really should be taking extra care to ensure your are insulting the right person. I did.

[DiTBho]

But, let me understand would you use the last offensive term you recently use in the other topic and call people "dumb moron" for this?

We all edit messages quickly, and make mistakes. However, if you are going to insult someone you really should be taking extra care to ensure your are insulting the right person. I did.

• I wrote "petulant", which is not an insult
• and I wrote it because I was tired of peter continuing to provoke. In that particular topic i just wanted to point out that if you don't master a toolchain, then it's advisable to stick to the simplest situation ever, where all the code runs in ram. It was a good suggestion, in my opinion, and it has nothing to do with anything he has to say unless I read the nonsense he continuely writes. If I put him on the ignore list I have my good reasons and he shouldn't break balls in every post about that

So, you who call others "dumb idiot sloppy", are nothing more than a superficial person who insults without understanding the context.

If you as sloppy in your software development as you were in editing your message in that thread, you definitely deserve the term.

The annoying thing is that you don't even try to understand others.
Enjoy my ignore list.

[mianos]

Ah, and thus we witness the inevitable descent of this discourse into a maelstrom of incendiary exchanges.

In my view, Doxygen-generated documentation is frequently as futile as having none at all. There are exceptions, such as the work seen on prefect.io, where meticulously curated embedded documentation is nothing short of exemplary. However, this success hinges on having a dedicated curator. Crafting proper documentation is a profession unto itself. While developers, myself included, possess the capability to produce it, the task demands a distinct mindset. I find it most effective to disengage from coding temporarily and return with a fresh perspective to tackle the documentation.

Regarding the term 'dumb moron,' it strikes me as poor English. After all, how many morons lack the attribute of being dumb? When I scrutinize code for half a day, only to discover some inane error of my own making, I simply label myself a moron. The redundancy of adding 'dumb' feels wasteful. When berating my own foolishness with two words, I opt for 'dumb fuck.'

[tggzzz]

The descent is not inevitable.

When applying such thoughts to myself, I tend to emulate the well-known bowl of petunias and say "oh no, not again".

Documentation requires the mindset of avoiding "how", and concentrating on "why" and "this is how you can use it". That goes in the class and/or package documentation. A few "why not" comments inside functions can be helpful, but they are invisible to documentation "generators".

[DiTBho]

In my view, Doxygen-generated documentation is frequently as futile as having none at all.

same opinion. I stopped using it a while ago.

dedicated curator. Crafting proper documentation is a profession unto itself

No doubt about 

Indeed, the life cycle of avionics software, where I work, is governed by DO178B(1) which, among other things, states that separations of roles is a must

• who does QA, does only that
• who does development, does only that
• who does testing, does only that
• who does documentation and review of the same, does only that

...

(1) but also hardware, which has similar directives and rules

[coppice]

The descent is not inevitable.

When applying such thoughts to myself, I tend to emulate the well-known bowl of petunias and say "oh no, not again".

Documentation requires the mindset of avoiding "how", and concentrating on "why" and "this is how you can use it". That goes in the class and/or package documentation. A few "why not" comments inside functions can be helpful, but they are invisible to documentation "generators".

The documentation that will be most valuable to people downstream, maintaining and working with the code, is actually the stuff that is invisible to any current automated tool in broad use. Whether its a high level document about the overall thing, or a comment like "this might seem stupid, but it deals with the following obscure situation......" somewhere in the code, put there after some long running bug was sorted out.

A number of writers have noted that starting again from scratch when a code base is a mess is almost always a losing strategy. However bad it may be, it will almost always include a lot of obscure job knowledge gained over the life of that code. Starting again throws that away. Even if a rework means changing almost all the code, if it can preserve that knowledge its a huge win over starting again. I agree with this point of view, but it says a lot about how bad even the best of current documentation is, that we all know the only place where you'll find all that stuff about the grubby details is in the actual code.

[Siwastaja]

Code: [Select]

    uint32_t           i1; /* irow */
    uint32_t           i0; /* icol */


Not here to judge and maybe you have a good reason of doing this, but whenever I catch myself of coming up with an indescriptive variable name and adding comment to explain what it actually is, and notice the comment is short enough to be used as variable name directly, I do this:
uint32_t irow;  // and the comment can be now removed

This I think is a perfect (maybe oversimplified though) textbook example of what is meant by self-documenting code: the irow comment can be used in code directly, and the advantage is that it now keeps visible in every access of that variable. Number of comments decreased, but IMHO code quality increased - which is also why number of comments is a poor indicator of quality.

[Postal2]

The day is not far off when people destined to work at McDonald's will be hired to write code for nuclear power plants. The history of the Challenger will repeat itself.

[radiolistener]

8. GitHub is the best tool for tracking and managing software development.

I don't think that it's the best, but it's flexible and many peoples know it so it helps to work together with more large team.

[unseenninja]

I don't want to see comments about what your code is doing. That should be self evident from the code (unless it has been deliberately written in an obfuscated style).
I want to see comments about why your code is doing what it does, what it works with and what it outputs.

This is where the actual business logic gets documented and it should always be there and should always be kept up to date.

I often end up having to maintain code which was written by others and find it immensely frustrating when I find no documentation of inputs and outputs or even the slightest clue as to why it does what it does. I see many people making the mistake of assuming that if they have to come back to code they wrote ten years ago that it will be obvious to them how it works and why it does what it does. It won't be.

In my opinion, some of the most selfish programmers out there are the ones who never write code thinking of how someone else will understand it if they need to make changes to it many years later when they no longer work at the company. Often I see people use this type of selfishness as a job security ploy. In a company which actually does software development properly, this kind of abusive behaviour should be spotted in code reviews and corrected before it gets into the codebase. Programmers who try this game repeatedly should be asked to look for a job elsewhere.

[Nominal Animal]

I want to see comments about why your code is doing what it does, what it works with and what it outputs.

I need to see comments describing why my code is doing what it does, and what I intended it to do in the first place, or the next time I look at it after a week or longer, I have to rewrite/refactor it because I can no longer remember.  I've written a lot of code in the last three decades plus.

[tooki]

I don't want to see comments about what your code is doing. That should be self evident from the code (unless it has been deliberately written in an obfuscated style).
I want to see comments about why your code is doing what it does, what it works with and what it outputs.

This is where the actual business logic gets documented and it should always be there and should always be kept up to date.

I often end up having to maintain code which was written by others and find it immensely frustrating when I find no documentation of inputs and outputs or even the slightest clue as to why it does what it does. I see many people making the mistake of assuming that if they have to come back to code they wrote ten years ago that it will be obvious to them how it works and why it does what it does. It won't be.

In my opinion, some of the most selfish programmers out there are the ones who never write code thinking of how someone else will understand it if they need to make changes to it many years later when they no longer work at the company. Often I see people use this type of selfishness as a job security ploy. In a company which actually does software development properly, this kind of abusive behaviour should be spotted in code reviews and corrected before it gets into the codebase. Programmers who try this game repeatedly should be asked to look for a job elsewhere.

What those people forget is that they themselves need the comments, too! Future you is just as clueless about the code as an outsider, unless you continue working with it on a daily basis forever, which frankly isn't likely.

[coppice]

I don't want to see comments about what your code is doing. That should be self evident from the code (unless it has been deliberately written in an obfuscated style).
I want to see comments about why your code is doing what it does, what it works with and what it outputs.

This is where the actual business logic gets documented and it should always be there and should always be kept up to date.

I often end up having to maintain code which was written by others and find it immensely frustrating when I find no documentation of inputs and outputs or even the slightest clue as to why it does what it does. I see many people making the mistake of assuming that if they have to come back to code they wrote ten years ago that it will be obvious to them how it works and why it does what it does. It won't be.

In my opinion, some of the most selfish programmers out there are the ones who never write code thinking of how someone else will understand it if they need to make changes to it many years later when they no longer work at the company. Often I see people use this type of selfishness as a job security ploy. In a company which actually does software development properly, this kind of abusive behaviour should be spotted in code reviews and corrected before it gets into the codebase. Programmers who try this game repeatedly should be asked to look for a job elsewhere.

What those people forget is that they themselves need the comments, too! Future you is just as clueless about the code as an outsider, unless you continue working with it on a daily basis forever, which frankly isn't likely.

Two somewhat conflicting related experiences:

• On at least two occasions I have written a utility a few pages long, and later found a much older file of mine which did exactly the same thing. I had no recollection of producing the older code. The two files matched to within a few characters. I'd used the same variable names, declared in the same order. I'd cooked up the same data structures. I'd broken the problem down to the same functions, with the same names, and the same parameters, declared in the same order. I'd written the same comments. Truly the two files were just a few characters different.  It would seem that, at least on some occasions, my future self can think exactly like my older self. Its weird how well those files matched, though. These were not massive programs, filled with intricate details to deal with the obscure.
• A number of times I have had to go back to code I produced a long time ago, to add to it, and found it extremely unfamiliar. I may or may not have remembered writing it, but I sure didn't remember any of the messy details of what it was up to. My future self very much relied on any guidance I had sprinkled through the work the first time through, especially the notes on the obscure situations which needed to be handled.

[Postal2]

.... A number of times I have had to go back to code I produced a long time ago, to add to it, and found it extremely unfamiliar. ...

You probably stole it from GitHub using copy-pasting.

[Nominal Animal]

.... A number of times I have had to go back to code I produced a long time ago, to add to it, and found it extremely unfamiliar. ...

You probably stole it from GitHub using copy-pasting.

I suspect that comment describes Postal2's own behavioural patterns, and has nothing to do with coppice.

If it was a tongue-in-cheek comment, I'm afraid it fell utterly flat: that kind of accusation can ruin friendships, you know, when people are actually proud of what they do, rather than do it just for the salary for now.

I, too, find my old code extremely unfamiliar.  This is because I do not memorize any details, and go through a lot of code.  Some of it I write myself, but I also examine a lot of open source projects' code (for a number of different reasons).  I often recognize my own style, though; and especially how I'm not satisfied with the information content in my comments.  (I can write acceptable code in over a dozen programming languages, and have been paid to do so in at least half a dozen, but comments are still the hardest to get exactly right.)

I never, ever, copy-paste others' code.  For one, I don't need to, as I don't have any reason to: no deadlines nowadays.  For another, having the code perform like I want to is much more important to me than having some code that seems to perform the way I can use.  Simply put, I do not write or show any code, whose behaviour I do not thoroughly understand.

Based on coppice's posts, noting they too have decades of software development experience, I'm betting they have the same attitude.

[Postal2]

... I, too, find my old code extremely unfamiliar. ...  Some of it I write myself, ...

But this part of hand-made code had to be commented out, because otherwise nothing worked.

[SiliconWizard]

Houston, I think we have a problem.

[Nominal Animal]

... I, too, find my old code extremely unfamiliar. ...  Some of it I write myself, ...

But this part of hand-made code had to be commented out, because otherwise nothing worked.

DO NOT MISQUOTE ME.

The full quote is "I, too, find my old code extremely unfamiliar.  This is because I do not memorize any details, and go through a lot of code.  Some of it I write myself, but I also examine a lot of open source projects' code (for a number of different reasons)."

The "Some of it" refers to the code I go through, not to "my old code", as your misquote implies.

I write all my old code myself, and keep proper attributions for others' code, as copyright and proper attributions and licensing happens to be very important to me.  I could never consider code written by someone else "my old code".

And no, I never have a problem where commenting out some code makes something work, and I don't understand why.  I just do not write or paste code I do not understand, ever.  It's been decades since I broke out of the "write some code and throw it at the compiler/interpreter until it sticks" phase.

I do understand you're just trying to get a rise out of me for "humorous reasons", but using a deliberate misquote is troll behaviour, and ought to get you in trouble.

[Postal2]

... I just do not write or paste code I do not understand, ...

I also, when I take code from GitHub, understand it well. However, I can easily distinguish it from mine, I don't have a situation when I don't recognize my code. I only know that if I don't recognize the code, it's not my code.

[coppice]

... I just do not write or paste code I do not understand, ...

I also, when I take code from GitHub, understand it well. However, I can easily distinguish it from mine, I don't have a situation when I don't recognize my code. I only know that if I don't recognize the code, it's not my code.

This account is seeming more like an AI than a troll. Maybe its some AI developer's test account. I'm coming to the conclusion that many classes of channel on YouTube are now dominated by people testing their AIs. Not channels trying to be obnoxious like Postal2, but things like the space related channels. They cover actual news, but in an uncoordinated way, with generally good pronunciation and intonation, they then say a simple common word in technical parlance in a wacky way, and make it obvious its not a human talking.

[tggzzz]

... I'm coming to the conclusion that many classes of channel on YouTube are now dominated by people testing their AIs....

Yoootooob has long been 99.9% crap. If it is now 99.99% crap, that doesn't change how you should regard it and use it.

[Siwastaja]

Yoootooob has long been 99.9% crap. If it is now 99.99% crap, that doesn't change how you should regard it and use it.

Such seemingly "small" change however makes it ten times as difficult to find non-crap, and this is a significant difference.

[tggzzz]

Yoootooob has long been 99.9% crap. If it is now 99.99% crap, that doesn't change how you should regard it and use it.

Such seemingly "small" change however makes it ten times as difficult to find non-crap, and this is a significant difference.

It actually makes it easier, in one of two ways.

Ignore all videos, and get on with your life.

Only watch a video where someone states why it will be worth your personal time (i.e. not theirs')

[Postal2]

... Maybe its some AI developer's test account. ...

I understand why you care about AI. It can scan your work and find that the "Hello world" program was definitely written by you (with lots of errors and comments).

[DiTBho]

It actually makes it easier, in one of two ways.
Ignore all videos, and get on with your life.
Only watch a video where someone states why it will be worth your personal time (i.e. not theirs')

When I read sentences like this I think ... but I don't earn anything from it, so can you blame the the system that pushes creators to upload rubbish just because this way they make money?

I saw a guy build bunkers with ... cardboard, wood, without insulation, without foundations, everything approximate, everything senseless, and yet it took him 2 weeks for every single video in the series (10 videos in total) and he earned no less than 5 million views per video, which, between monetization and sponsors I don't know how much it earned him but it certainly was a lot of money.