I'm Bill I don't comment my code (except complex parts), instead I try to make code clear, including using proper variable and function names and try to keep functions short. I don't think I ever got lost in my own code in my 20+ years of experience. Even got complements about it.
The programming language is meant for humans to read/write, if you need to put comments to understand your code then your code sucks.
Commenting is an art. Too much and it is outright misleading after the first hotfix. Too little and only the original developer can maintain it
But uncommented code is a dick move. And, more importantly, it means you can't punt bug fixes to the intern
Use comments to describe the philisophy of the code, the why. And any non obvious extended relationships. Risk. Etc.
Comments on function are typically a waste of space.
When writing basic business code, structuring the code well and having good naming standards means you shouldn't need a ton of comments, but you should still have some. Plus, using structured function content blocks gives you intellisense in some languages and IDEs, which is important for code reuse in teams.
However, when I was doing scientific programming I'd have comments for almost every line at times where I put the mathematical formula and operations the line represents. Implementing a convolution neutral network with parameters to dynamically scale the layers or MPI stochastic simulations is much different than writing CRUD functions or basic business logic.
Comments are there to make your ctrl + f’s faster
Bill never revisits his code.
Bill is a contractor smart.
NGL that is one of the best parts about being a contractor.
So many hackjobs. Sorry maintainers.
We all envy you more than we hate you
A technical debt escapist.
Bill changes jobs every two years to outrun the crushing weight of institutional responsibility.
Comments are lies that will happen sometime in the future
Comments are always overlooked if gode gets refactored. Language servers can't/won't parse them and they're easy to overlook.
If you name your functions/variables clearly, put complex logic into clearly named functions and keep the same level of abstraction in every function (which never exceeds roughly 50 lines), you hardly need any comments, if any.
Comments are for behavior that's not possible to convey clearly through code.
If a block of code needs a comment, then you can easily move that block into a function and summarise the comment into a name for that function. If you can not easily move a block of code into a function, then you may need to rethink your design.
This isn’t always true of course, but it’s a good mindset to have.
Bill writes spaghetti code.
Bill is not smart.
Don’t be like Bill.
Wow this job has massive amounts of unnecessary stress, I wonder what the cause can be.
The cause is me, 6 months ago.
(Written for comedic purposes only. Managers are my single source of stress)
Me: writes code^1, doesn't comment
Me, six months later: what idiot wrote this shit?!
Only developer on project
Time to plan a 3-day workshop with yourself at the pub to get it together
This is Bill.
Bill doesn't need to minify his code, he names things using a single character even in compiled languages.
Bill is a heckin chad who can guess what the code does merely by looking at types and control flow.
Be like Bill
I started coding with TurboBasic. My favorite thing about TB was that you could have variable names of any length but the compiler only used the first two letters - and case insensitive at that. So "Douchebag" and "doorknocker" looked like different variables but were actually the same thing.
Is the Greek question mark a legal identifier for variable names?
I'm no heckin chad like bill ima soyjak :(
Remembered*
Bill DID forget.
Classic comments.
Code is spaghetti.
Comments describe what it used to do.
Comments are no longer relevant.
Comments should be about how/what a code block does something.
Not what a line of code does
I don't care how much you think your code is readable, plain text comments are readable by everyone no matter the proficiency in the programming language used. That alone can make a huge difference when you're just trying to understand how someone handled a situation.
Comments explain why, not what. Any comments that explain what a section of code is doing would probably be better off as separated methods.
Apart from basic documentation comments, like JavaDoc or C#'s XML documentation comments.
There's nothing limiting what a comment should be as far as I know.
As an example of what I mean, I've seen in a 10k+ lines python code a few lines of bit manipulation. There was a comment explaining what those lines did and why. They didn't expect everyone to be proficient in bit manipulation but it made it so that anyone could understand anyway.
There’s nothing limiting what a comment should be as far as I know.
Nothing technical, sure. Just good coding practices.
There's nothing keeping the comments up to date with the code. Comments should be sparse and only on sections that aren't obvious why they're being done
I hate fixing other people's code. It is one of the reasons I don't like letting an AI write my code first draft either.
Comment your code but only with numbers and then write a manual
Yeah, proper documentation is not done with comments in code, but it's a project in and of itself. Proper documentation is also fucking hard and I have no idea how people (in open source projects) can do it. It's so fucking boring and tedious, especially when there are a million interesting problems you could tackle instead. Mad respect for people writing documentation, seriously.
I also hate writing comments and prefer to just write out everything in code.
I write the shit in the explanation before programming it, its a way to construct a code in human language and logic, with my manual you could program the exact same program in another programming language. (i cant show it because what i program is company secret, including the manual) and yes its kinda boring but everyone is grateful for it and for the things i do i need to make shure its never failing, so its checked by several different people, and such a manual helps a lot for everyone.
yep. Good code is self-documenting and syntax highligting and having longer sections folded up may help more than having to process some greyed out text. But comments are still useful for generating proper autocompletion and avoiding having to skim through you '"self documenting code". Also it helps greatly with TDD and maintaining good coding practices. For example if you need a numbered list to reliably sum up what some function does, it's often a good sign that it should be broken into a couple smaller ones.
10 months? More like a weekend for me.
Basic rule if someone claims X magically solves a problem they don't follow X and are a huge generator of the problem.
For example people who claim they don't need to write comments because they write self documenting code are the people that use variable names x1,x2,y, etc..
Similarly anyone you meet claiming Test Driven Development means they have better tests will write code with appalling code coverage and epically bad tests.
The reason there are no comments in the code? Written by ChatGPT.
It appears you haven’t used chat gpt for coding help.
ChatGPT actually puts a lot of comments in, especially when minor modifications are needed to make something work.
I'm Bill I don't comment my code (except complex parts), instead I try to make code clear, including using proper variable and function names and try to keep functions short. I don't think I ever got lost in my own code in my 20+ years of experience. Even got complements about it.
The programming language is meant for humans to read/write, if you need to put comments to understand your code then your code sucks.
Commenting is an art. Too much and it is outright misleading after the first hotfix. Too little and only the original developer can maintain it
But uncommented code is a dick move. And, more importantly, it means you can't punt bug fixes to the intern
Use comments to describe the philisophy of the code, the why. And any non obvious extended relationships. Risk. Etc.
Comments on function are typically a waste of space.
When writing basic business code, structuring the code well and having good naming standards means you shouldn't need a ton of comments, but you should still have some. Plus, using structured function content blocks gives you intellisense in some languages and IDEs, which is important for code reuse in teams.
However, when I was doing scientific programming I'd have comments for almost every line at times where I put the mathematical formula and operations the line represents. Implementing a convolution neutral network with parameters to dynamically scale the layers or MPI stochastic simulations is much different than writing CRUD functions or basic business logic.
Comments are there to make your ctrl + f’s faster
Bill never revisits his code.
Bill is
a contractorsmart.NGL that is one of the best parts about being a contractor.
So many hackjobs. Sorry maintainers.
We all envy you more than we hate you
A technical debt escapist.
Bill changes jobs every two years to outrun the crushing weight of institutional responsibility.
Comments are always overlooked if gode gets refactored. Language servers can't/won't parse them and they're easy to overlook.
If you name your functions/variables clearly, put complex logic into clearly named functions and keep the same level of abstraction in every function (which never exceeds roughly 50 lines), you hardly need any comments, if any.
Comments are for behavior that's not possible to convey clearly through code.
If a block of code needs a comment, then you can easily move that block into a function and summarise the comment into a name for that function. If you can not easily move a block of code into a function, then you may need to rethink your design.
This isn’t always true of course, but it’s a good mindset to have.
Bill writes spaghetti code.
Bill is not smart.
Don’t be like Bill.
Wow this job has massive amounts of unnecessary stress, I wonder what the cause can be.
The cause is me, 6 months ago.
(Written for comedic purposes only. Managers are my single source of stress)
Me: writes code^1, doesn't comment
Me, six months later: what idiot wrote this shit?!
Time to plan a 3-day workshop with yourself at the pub to get it together
This is Bill.
Bill doesn't need to minify his code, he names things using a single character even in compiled languages.
Bill is a heckin chad who can guess what the code does merely by looking at types and control flow.
Be like Bill
I started coding with TurboBasic. My favorite thing about TB was that you could have variable names of any length but the compiler only used the first two letters - and case insensitive at that. So "Douchebag" and "doorknocker" looked like different variables but were actually the same thing.
Is the Greek question mark a legal identifier for variable names?
I'm no heckin chad like bill ima soyjak :(
Remembered*
Bill DID forget.
Classic comments.
Code is spaghetti.
Comments describe what it used to do.
Comments are no longer relevant.
Comments should be about how/what a code block does something.
Not what a line of code does
I don't care how much you think your code is readable, plain text comments are readable by everyone no matter the proficiency in the programming language used. That alone can make a huge difference when you're just trying to understand how someone handled a situation.
Comments explain why, not what. Any comments that explain what a section of code is doing would probably be better off as separated methods.
Apart from basic documentation comments, like JavaDoc or C#'s XML documentation comments.
There's nothing limiting what a comment should be as far as I know.
As an example of what I mean, I've seen in a 10k+ lines python code a few lines of bit manipulation. There was a comment explaining what those lines did and why. They didn't expect everyone to be proficient in bit manipulation but it made it so that anyone could understand anyway.
Nothing technical, sure. Just good coding practices.
There's nothing keeping the comments up to date with the code. Comments should be sparse and only on sections that aren't obvious why they're being done
I hate fixing other people's code. It is one of the reasons I don't like letting an AI write my code first draft either.
Comment your code but only with numbers and then write a manual
Yeah, proper documentation is not done with comments in code, but it's a project in and of itself. Proper documentation is also fucking hard and I have no idea how people (in open source projects) can do it. It's so fucking boring and tedious, especially when there are a million interesting problems you could tackle instead. Mad respect for people writing documentation, seriously.
I also hate writing comments and prefer to just write out everything in code.
I write the shit in the explanation before programming it, its a way to construct a code in human language and logic, with my manual you could program the exact same program in another programming language. (i cant show it because what i program is company secret, including the manual) and yes its kinda boring but everyone is grateful for it and for the things i do i need to make shure its never failing, so its checked by several different people, and such a manual helps a lot for everyone.
yep. Good code is self-documenting and syntax highligting and having longer sections folded up may help more than having to process some greyed out text. But comments are still useful for generating proper autocompletion and avoiding having to skim through you '"self documenting code". Also it helps greatly with TDD and maintaining good coding practices. For example if you need a numbered list to reliably sum up what some function does, it's often a good sign that it should be broken into a couple smaller ones.
10 months? More like a weekend for me.
Basic rule if someone claims X magically solves a problem they don't follow X and are a huge generator of the problem.
For example people who claim they don't need to write comments because they write self documenting code are the people that use variable names x1,x2,y, etc..
Similarly anyone you meet claiming Test Driven Development means they have better tests will write code with appalling code coverage and epically bad tests.
The reason there are no comments in the code? Written by ChatGPT.
It appears you haven’t used chat gpt for coding help.
ChatGPT actually puts a lot of comments in, especially when minor modifications are needed to make something work.