I am still bad about it, learned SQL from my last job and I was always but spitting out the code. It would be nice and uniform in my editor but otherwise it was confusing coming back a year later after something broke
People code like how I name my files After a day, I’ve completely forgotten what was inside of it because it’ll be named something like “butternut squash”
I've definitely seen a third type: the exhausted exasperated coder comment. "Do not change this. It works. No-one knows why, but if you change it nothing works any more. DO NOT TOUCH."
@NIX-FLIX The typical reason for out of bounds items is to hide them from the player's eyes. If it's a model, it's probably so that the game only has to load in that file when the area is loaded, not wherever that item is used.
@@niceuser2face611Fallout 4 did this but instead out of bounds objects fixing things it’s out of bounds objects causing crashes, like Willy’s Wonderland in Nuka World with the worms that crash the game making the area unplayable. There’s mods that clean these out of bounds objects up but Bethesda should fix these kinds of game breaking out of bounds objects.
I was always told by my professors in college "comment your code like you know the next engineer to look at it is a serial killer and knows where you live" 😂
We heard more of a "Your job is making it useable for the dumbest possible user, don't become the dumbest possible user yourself by not knowing what you've done anymore".
your teacher is a good teacher. mine just told "yea, this is clean code. do this, so the next person knows what the heck you were doing." nobody did that, he came in at some random day afterwards and said "okay now everyone, stop coding, and sit on the chair of the person right by your side. you gonna see now why clean code is important." from that day, everyone started commenting.
some people are so obsessed with avoiding comments that they'd rather use an anonymous function to give something a name rather than just writing a comment. it's quite strange.
What is not terrible - it's just "not as good" as a why. And if you need a what comment, it may indicate a needed why comment somewhere else. It's fine as a placeholder until they why becomes clear to the coder.
I agree that saying "what" comments are bad is a bit reductive in a vacuum. I've yet to see a style guide that takes this stance. I've seen plenty of 'don't add redundant comments', but not "what == bad" Most people would agree that "what" comments are great for things like docstrings, header files or wherever the interface is declared/exposed, and spots where there are variables or functions with unclear names. They're also used for a lot of reference documentation. That said, he's putting in an inline comment to describe a process/behavior/interaction that isn't evident by the name or adjacent context by setting that value, which understandably lends to a "why" comment. If I were to look at that Potion object I would probably assume "unbreaking" was a property it applied to whoever used it, not an attribute of the potion object itself. I can only hope the nuance isn't lost on people and they don't take his verbatim statement at face value.
@@louisrobitaille5810i think the better reasoning for zero based indexing is that zero represents an offset, not an order. a basic array isnt a list of numbers, its a pointer to a series of numbers; youre not accessing the zeroth element of the array, but zero strides away from the start of the array.
@@ratofthecity6351 Aren't the 0th stride and the 0th element the same thing 🧐? Item 0, item 1, item 2, item 3, and so on. People're just too used to counting from 1 to 10 instead of 0 to 9, despite it being basically same thing (in this context) 🤔.
In my work, I like to think of it like this: any comments or details left must be able to clearly explain a given thing to someone who knows little about what they're looking at. I do this with my emails, my invoices, and my client interactions... usually helps to prevent a lot of questions or mess-ups down the line.
My first and only post to stack overflow was in high school. I was submitting a basic coding assignment that i was presenting to my class later that was filled with comments like thor is recommending. I was asking a general question about commenting etiquette in java and explained what i was doing with it. I was torn apart and told that i was pretty much the devil for having more than one comment block above each function block and that i was stupid for not using the standard format for every comment. Have never logged into stackoverflow never again.
I appreciate the drive in recent years to write code that uses thoughtful naming that strives to be self documenting. I certainly don’t miss variables in longish methods named “x”. But I do think we should write more of these sorts of comments to explain what we were thinking when we wrote code.
recently, i was taking two university programming courses. i got whiplash when one of them banned comments almost entirely and encouraged thoughtful naming, the other course pretty much demanded comments every other line and the norm was using abbreviated or one letter names for some reason.
My uni professor told us we had to write comments for every single line of code we wrote. It taught us more than anything to just write shit comments. This is the same professor who for our final eval had us hand writing code with pen and paper, and he took marks away for unclear indentation and other crap @crediblesalamander8056
The change in common aspect ratio from 4:3 to 16:9/16:10 was an underappreciated godsend for programming. I used to adhere to lines having a maximum width of 80 characters, but nowadays my minimum maximum width is at least 120 characters. It'd be even longer if I didn't default to always having two editor frames side by side. The prevalence, accessibility, and support of IDEs (or more importantly their autocomplete/assist) is the other side of the coin. Longer names are significantly less annoying when you don't have to manually type them out in full every time.
i think as modern coders had to finally start fundamentally modifying infrastructure that was written in not particularly intuitive high level languages like js, being frustrated by not being able to read code became like this universal stressor to coders, so there was this grassroots renaissance where everyone came together and got their shit together to make everything more legible.
Same, but as someone learning computer science, this is helpful. Also do you know how hard it is to read someone else’s code? If you want to try I have a community post of some code I made, try to see what it does and tell me if you can understand it.
I try to live by this quite a good bit. When I tell people at work about how I might do things or what different safety rules are I try to tell them WHY I/we do that/have it as a rule. Becuase most of the time people seem to be more receptive to things when they know the reason behind it, not just “hey (don’t) do that thing!”
@@TheScorch191and even then it only works while you're around to enforce it. Like cats and spray bottles. And yeah, I've had like a 90% hitrate with starting to care about restrictions after learning the actual reasoning behind them. I didn't care about hearing protection until learning about resonance and human ears and the actual mechanics of hearing loss. I didn't take electricity or flammables seriously until learning the details of that physics/chemistry, and exactly how careless mistakes can murder you. The other 10% are restrictions that I gleefully ignore after learning they have little to no reasoning behind them.
I would augment this by noting that a lot of the reason people write those bad comments is to remind themselves of how the programming language works cause they’re juggling too much of the system in their brain. Plotting down some design context as part of your ‘why’ is often more helpful. In the video, I’d refer to enchant too, something as follows: Unbreakable is an item enchant property that prevents this item from disappearing when used if set. 1 is the default value. Then you can in theory extend and/or move this to code documentation later if you have to cause ya did enough of the work when it hurt your brain the most.
This is exactly what I am doing when working, and someone tells me to do something new or that I am unfamiliar with: do not just tell me WHAT to do but also WHY. That way, I can perform the task with the goal in mind to achieve the best result.
This reminds me of the "Real Programmers" jokes we used to tell back in the mid 1980's, specifically: Real Programmers don't comment code. If it was that hard to write, it should be that hard to figure out.
"This was part of a failed feature, but removing or otherwise altering it in any way shatters the entire program. I don't know why. I've tried fixing it, but the only solution was to leave this as if it was still interacting with the scrapped feature."
Ideally, well-written code should explain the “what” for itself. Clearly-named variables, functions and intuitively structured code can often remove the need for comments entirely
I had a professor in college that said "Those who know how will always work for the ones who know why." Blew my little brain at the time but stuck with me my whole life.
I love how in this short, he only explains what you should do, but not why. Obviously, in this case, it's really not needed, but it's still kinda ironic.
Reminds me of when I had a hashtable with linkedlists that had to grow when any of the linkedlists got to a certain length, it had to grow. So I called my hashtable dict, and I called my growth function stroke... Cause in order to make your dict grow, you have to stroke it
I love your content, your mindset is rare and very few people unlock perspective and knowledge and have the ability to combine that, you teach alot of people things that change their lives, sometimes they don't realize it until after.... None the less... Please more info about programming like this :)
Back then was taking QA classes our teachers always said: -Make your test cases clear and simple, so simple that someone who doesnt know anything abaut QA could understand what to do. So I tryed showing them to few people to check that. No one cared to look...
As someone that LOVES digging through other peoples coding and script, THANK YOU! Good comments should be more common, as a bonus say you cooperate with someone to write software, IF YOU DONT COMMENT WHAT DOES WHAT you cant be pissed if they accidentally break something trying to fix another SIMILIAR THING!
i had to manually search you uo because its been months since you were naturally reccomended to me and your shorts and noel’s are the nourishment i need
it's like the settings in the BIOS >enable TPM >click on it to get explanation >this setting enables or disables TPM OH WOW THANK YOU THIS TOTALLY EXPLAINS IT
I will add one inglorious exception: when you comment a more complicated function before writing, then leave it in because you're proud it all worked out.
I'm not even a programmer but I feel like this advice extends to more fields. Anyone can figure out what something does if they're taught or can even use context clues. It's a lot harder to figure out why it's there because function may not have obvious implication. Hence a 'why' is way more valuable than a 'what'. Anyone who reads your code now knows your thought process and the function's purpose.
To be fair, "This sets unbreaking to 1" as a comment for "unbreaking: 1" is like posting a sign above a door that reads "This is for going through". That's some high levels of "No shit sherlock" right there :P
PR reviews are so important for deciding where comments are needed. I often find that pieces of code I imagined would be confusing to other devs are self explanatory to them, and if I add too many comments they will read right past them and miss the important ones
I'm getting back into programming, I haven't done it since college in 07. I probably wouldn't have of. If it weren't for you inspiring me. Originally I learned visual basic and SQL. But I found an app to learn Python on. And it feels as exciting as learning programming for the first time again.
Depends on the language, method of coding and situation. There can be bigger chunks of code that doesn't make sense to put in a function. So it's useful to write a comment describing what the following block does. "Why" is useful when it's obvious what the code does.
it's about why being more important than the what, it's about the why typically being less obvious than the what. Explain what isn't obvious. Are you literally ust assigning a value to a variable? The why is going to be less obvious. Are you checking if the players health is still positive after being attacked? The why is self explanatory, but the what might still be worth documenting. I for sure agree that the why is typically what is more important, but it's more complicated than just "document why, not what"
This is actually pretty helpful. I will now promptly ignore it because listening means rewriting hundreds of comments because i went for the "quantity over quality" route.
I think this kinda thing should be also be known even for conversations. A great example is telling kids, "because I said so" or "because I'm your parent," saying that doesn't teach reasoning.
As I sit here, nearly midnight, mere days after I thought to myself that I want to learn how to work in s&box (and godot sometime but that's a whole other wheelhouse) I am glad to see this. I may have a small amount of programming in my background but having good comments eluded me
I did a stint as a programmer before changing paths to become an Art Therapist. When working with code the number of times I wish there was reasoning behind the old code rather than just useless comments was uncountable. It really made it hard to know when adding or changing anything if it was also somehow changing other important things without knowing because the code wasn't well documented or in some cases with the really old code, just so inefficiently written.
Comments should never explain what code does, because if someone can't just read it and understand what it does then it's bad code. 100% agree that comments should be about why that code was necessary.
From someone learning how to code from scratch, thank you. Very few instruction courses really anywhere state anything like this even though one would think it's common sense to do this. Yea, I'm serious.
At my job, my team has a rule of no comments. The purpose is to force us to write meaningful names for everything, and promote encapsulation whenever possible. This philosophy has been working quite well on our projects. I know it's not "one size fits all", though.
In most cases, type b is backed by source control. You can click on a line and see its commit message. It's less error prone and less verbose, and only fails if anyone manages to erase all relations to source control. In that sense, for most modern devs its perfectly okay to not comment in code.
Type one was what we were told to do at uni. On my first job, I wanted to make the best impression and made sure to put them *everywhere*. Nobody cared until, two years later, we needed to share the code with our partners. Wouldn't be surprised if some of that is still there
I cant remember who the creator was but back when i was coding basic menus for campaign GTA V, I used someones menu that they uploaded as a learning document and i swear to god, every single unique line of code was explained. From "this line sets the key that is used to open the menu" to "this line uses r,g,b values to set the colour for all slider bars. Only takes effect if previous line is set to 0". It was a coding noobie's wet dream 😂
As a brand new programmer, who also just saw the Necro thread post, I feel like there is an oppurtunity here for a joke between these two shorts that could be VERY funny.
"Yes, this causes a Memory Leak. Too bad!" "This is bad dumb code but more importantly it's bad dumb code that does nothing. Why? Did it ever?" "My hope with this code is that I am never allowed to work on GUI ever again."
@@DavBotsArcade “when writing code only programmer and god knows what the code does. Few weeks later only god knows” this is the truest wisdom anyone has ever said about software development.
I've been doing this actually, but mostly because I forget how or why I used certain code, so I over-explain things to my self so I know future me will understand it.
Remember profs hounding people for comments in homework, thought it was stupid. Now I’m real world (and working on 13 year old code), I believe no comments should be automatic failure for an assignment.
I work at a bank and I wish people would apply this to when they leave holds and comments on accounts. I don't want you to write "hard hold" I want to know WHY. Or god forbid they put "Ask favorite animal" when there are 3 people on the account and the answer isn't even in our system!!!!
Code should be as self discriptive as possible. This is usually done with good discriptive variable/class/type/function names. It is also done by programming to the affirmative if possible (and some other good patterns). Comments should only be used to describe the reasoning behind something, if it is not apparent. (Or automation designed to look at comments like an doc generator).
So here's what I've learned: Bad comment: This is a video on comments Good comment: I should make more useful and non-redundant comments on things, because that will make my comments more useful and non-redundant. Wait, I think I did it wrong...
Breaking news: programmer writes unreadable code; Refuses to comment.
this is one of the funniest jokes ive read in months
Care to comment?
This deserves a heart from Thor.
The 3rd type of comment lol
I am still bad about it, learned SQL from my last job and I was always but spitting out the code. It would be nice and uniform in my editor but otherwise it was confusing coming back a year later after something broke
"I don't remember what this does, but deleting it breaks everything"
tf2 dev comment momemt
Riot, looking at the mess of spaghetti code that is league of legends:
People code like how I name my files
After a day, I’ve completely forgotten what was inside of it because it’ll be named something like “butternut squash”
The holy pineapple
The legendary coconut.jpg
“# TODO: Fix this”
Me after every 2 lines of code
# DO NOT PUSH THIS TO PRODUCTION
*currently looking at production code.
#forgot what "this" was
*written in 2017* me reviewing the code 7 years later...
@@blanq820bro why does that sound perfectly like it’s from a game made before 2014
I've definitely seen a third type: the exhausted exasperated coder comment. "Do not change this. It works. No-one knows why, but if you change it nothing works any more. DO NOT TOUCH."
The fabled “out of bounds tomato of gravity” if it’s gone the entire game stops Physicsing
@@niceuser2face611 I always assumed developers had reasons to put random objects out of bounds that affect the entire level apparently not
@NIX-FLIX The typical reason for out of bounds items is to hide them from the player's eyes. If it's a model, it's probably so that the game only has to load in that file when the area is loaded, not wherever that item is used.
Ah yes tf2
@@niceuser2face611Fallout 4 did this but instead out of bounds objects fixing things it’s out of bounds objects causing crashes, like Willy’s Wonderland in Nuka World with the worms that crash the game making the area unplayable. There’s mods that clean these out of bounds objects up but Bethesda should fix these kinds of game breaking out of bounds objects.
I was always told by my professors in college "comment your code like you know the next engineer to look at it is a serial killer and knows where you live" 😂
We heard more of a "Your job is making it useable for the dumbest possible user, don't become the dumbest possible user yourself by not knowing what you've done anymore".
comment your code like the reader is a kernel dev
your teacher is a good teacher. mine just told "yea, this is clean code. do this, so the next person knows what the heck you were doing." nobody did that, he came in at some random day afterwards and said "okay now everyone, stop coding, and sit on the chair of the person right by your side. you gonna see now why clean code is important." from that day, everyone started commenting.
@arthurvergolino6859 lol that's one way to teach commenting lol
WHY is always good, but WHAT has its place; I can appreciate WHAT comments that mark the borders between components.
some people are so obsessed with avoiding comments that they'd rather use an anonymous function to give something a name rather than just writing a comment. it's quite strange.
Most people can visually see what a thing does, though.Especially if you name it correctly
What is not terrible - it's just "not as good" as a why.
And if you need a what comment, it may indicate a needed why comment somewhere else. It's fine as a placeholder until they why becomes clear to the coder.
@@blackjacktrialthere are times where what is more important than why, but that’s usually in ASM or some globally managed dumpster fire.
I agree that saying "what" comments are bad is a bit reductive in a vacuum. I've yet to see a style guide that takes this stance. I've seen plenty of 'don't add redundant comments', but not "what == bad"
Most people would agree that "what" comments are great for things like docstrings, header files or wherever the interface is declared/exposed, and spots where there are variables or functions with unclear names. They're also used for a lot of reference documentation.
That said, he's putting in an inline comment to describe a process/behavior/interaction that isn't evident by the name or adjacent context by setting that value, which understandably lends to a "why" comment. If I were to look at that Potion object I would probably assume "unbreaking" was a property it applied to whoever used it, not an attribute of the potion object itself.
I can only hope the nuance isn't lost on people and they don't take his verbatim statement at face value.
There're 2 types of comments:
2. The bad ones
1. The good ones
0. The nonexistant ones.
zero indexing my beloathed
@ Zero indexing is the mathematically logical indexing. Digits in order are 0, 1, 2, …, 8, 9. Everything starts at 0, not 1 😅.
@@louisrobitaille5810 you're right but that doesn't mean I have to like it!
@@louisrobitaille5810i think the better reasoning for zero based indexing is that zero represents an offset, not an order. a basic array isnt a list of numbers, its a pointer to a series of numbers; youre not accessing the zeroth element of the array, but zero strides away from the start of the array.
@@ratofthecity6351 Aren't the 0th stride and the 0th element the same thing 🧐? Item 0, item 1, item 2, item 3, and so on. People're just too used to counting from 1 to 10 instead of 0 to 9, despite it being basically same thing (in this context) 🤔.
In my work, I like to think of it like this: any comments or details left must be able to clearly explain a given thing to someone who knows little about what they're looking at.
I do this with my emails, my invoices, and my client interactions... usually helps to prevent a lot of questions or mess-ups down the line.
it'd also help you understand what you did or why, later when you check them
@@chlmlwho is future you if not someone liable to have become unfamiliar with previous work
@@akuro6470idk who future me is but past me is a lazy bastard who leaves me to deal with his fuckups. I hate that guy 😂
My first and only post to stack overflow was in high school. I was submitting a basic coding assignment that i was presenting to my class later that was filled with comments like thor is recommending. I was asking a general question about commenting etiquette in java and explained what i was doing with it. I was torn apart and told that i was pretty much the devil for having more than one comment block above each function block and that i was stupid for not using the standard format for every comment. Have never logged into stackoverflow never again.
There is another.
// DO NOT TOUCH
Context is in great demand but poor supply
I appreciate the drive in recent years to write code that uses thoughtful naming that strives to be self documenting. I certainly don’t miss variables in longish methods named “x”.
But I do think we should write more of these sorts of comments to explain what we were thinking when we wrote code.
recently, i was taking two university programming courses. i got whiplash when one of them banned comments almost entirely and encouraged thoughtful naming, the other course pretty much demanded comments every other line and the norm was using abbreviated or one letter names for some reason.
@ we seem hard coded as a species to want absolute rules that mean we can stop thinking, when the optimal stance is often fuzzy
My uni professor told us we had to write comments for every single line of code we wrote. It taught us more than anything to just write shit comments.
This is the same professor who for our final eval had us hand writing code with pen and paper, and he took marks away for unclear indentation and other crap @crediblesalamander8056
The change in common aspect ratio from 4:3 to 16:9/16:10 was an underappreciated godsend for programming.
I used to adhere to lines having a maximum width of 80 characters, but nowadays my minimum maximum width is at least 120 characters. It'd be even longer if I didn't default to always having two editor frames side by side.
The prevalence, accessibility, and support of IDEs (or more importantly their autocomplete/assist) is the other side of the coin. Longer names are significantly less annoying when you don't have to manually type them out in full every time.
i think as modern coders had to finally start fundamentally modifying infrastructure that was written in not particularly intuitive high level languages like js, being frustrated by not being able to read code became like this universal stressor to coders, so there was this grassroots renaissance where everyone came together and got their shit together to make everything more legible.
Saw the title and thought he was talking about UA-cam comments
# this comment is here because user misunderstood the purpose of the video initially, but all was cleared up
I am incredibly disappointed
Same
Same, but as someone learning computer science, this is helpful. Also do you know how hard it is to read someone else’s code? If you want to try I have a community post of some code I made, try to see what it does and tell me if you can understand it.
Same when I got the notification
I try to live by this quite a good bit. When I tell people at work about how I might do things or what different safety rules are I try to tell them WHY I/we do that/have it as a rule. Becuase most of the time people seem to be more receptive to things when they know the reason behind it, not just “hey (don’t) do that thing!”
"because I told you" only works with little kids
@@TheScorch191and even then it only works while you're around to enforce it. Like cats and spray bottles.
And yeah, I've had like a 90% hitrate with starting to care about restrictions after learning the actual reasoning behind them. I didn't care about hearing protection until learning about resonance and human ears and the actual mechanics of hearing loss. I didn't take electricity or flammables seriously until learning the details of that physics/chemistry, and exactly how careless mistakes can murder you.
The other 10% are restrictions that I gleefully ignore after learning they have little to no reasoning behind them.
When I saw the title, I assumed he was referring to UA-cam comments.
Same
Nice rack!
I would augment this by noting that a lot of the reason people write those bad comments is to remind themselves of how the programming language works cause they’re juggling too much of the system in their brain. Plotting down some design context as part of your ‘why’ is often more helpful. In the video, I’d refer to enchant too, something as follows:
Unbreakable is an item enchant property that prevents this item from disappearing when used if set. 1 is the default value.
Then you can in theory extend and/or move this to code documentation later if you have to cause ya did enough of the work when it hurt your brain the most.
So a what comment is an interim why comment.
It's not awful, but it's incomplete.
We set unbreaking here because otherwise this item will disappear when used…
Because otherwise the game will…..
…Break…
I’ll show myself out😂
That's a good comment!
This is exactly what I am doing when working, and someone tells me to do something new or that I am unfamiliar with: do not just tell me WHAT to do but also WHY. That way, I can perform the task with the goal in mind to achieve the best result.
The number one thing I learned so far is that you should be explaining things to people as if they are babies who don’t know anything
…especially when the “people” is me in 3 months and I’ve forgotten everything I was thinking at the time
@@lkyuvsad more like 1 week, on good days 2 hours if we're being honest.
The entire legacy of good coding practices was apparently wadded up and stuffed into Thor's head because nobody else does this
This reminds me of the "Real Programmers" jokes we used to tell back in the mid 1980's, specifically:
Real Programmers don't comment code.
If it was that hard to write, it should be that hard to figure out.
“Comments are for bad programmers’ code.”
"This was part of a failed feature, but removing or otherwise altering it in any way shatters the entire program. I don't know why. I've tried fixing it, but the only solution was to leave this as if it was still interacting with the scrapped feature."
"The person who knows "How" will always have a job. The person who knows "Why" will always be their boss.
"We don't know why this works. A priest has been called."
Ideally, well-written code should explain the “what” for itself. Clearly-named variables, functions and intuitively structured code can often remove the need for comments entirely
I can read code just fine, but I can’t read my coworkers minds.
Comment: "remove after launch"
Gitblame: 8 years ago
I had a professor in college that said "Those who know how will always work for the ones who know why." Blew my little brain at the time but stuck with me my whole life.
I love how in this short, he only explains what you should do, but not why.
Obviously, in this case, it's really not needed, but it's still kinda ironic.
alternatively, write an entire novel. give that one thing an entire origin story
Reminds me of when I had a hashtable with linkedlists that had to grow when any of the linkedlists got to a certain length, it had to grow. So I called my hashtable dict, and I called my growth function stroke... Cause in order to make your dict grow, you have to stroke it
I learn so much from Thor. It’s refreshing to see some one with morals use there powers for good.
There are some pretty hilarious, expletive-laced comments that fall into a 3rd kind.
the most important part of communication is context 100%
I love your content, your mindset is rare and very few people unlock perspective and knowledge and have the ability to combine that, you teach alot of people things that change their lives, sometimes they don't realize it until after.... None the less... Please more info about programming like this :)
Back then was taking QA classes our teachers always said:
-Make your test cases clear and simple, so simple that someone who doesnt know anything abaut QA could understand what to do.
So I tryed showing them to few people to check that. No one cared to look...
That sounds like any law ever made, same as pretty much any contract ever made tbh.
As someone that LOVES digging through other peoples coding and script, THANK YOU! Good comments should be more common, as a bonus say you cooperate with someone to write software, IF YOU DONT COMMENT WHAT DOES WHAT you cant be pissed if they accidentally break something trying to fix another SIMILIAR THING!
i had to manually search you uo because its been months since you were naturally reccomended to me and your shorts and noel’s are the nourishment i need
As a cool sci student I must say thank you
# this jpg of a coconut is here because deleting it will break the game
Code is read more than written, and very few things hurt more than looking at yesterday’s code without a clue as to why it’s there.
it's like the settings in the BIOS
>enable TPM
>click on it to get explanation
>this setting enables or disables TPM
OH WOW THANK YOU THIS TOTALLY EXPLAINS IT
I will add one inglorious exception: when you comment a more complicated function before writing, then leave it in because you're proud it all worked out.
I literally me proof my notes for everything, because months later, i forget the context hundred percent.
"WHY?!" -Thor Goblinsson
I started saying "yes" out loud when watching this short because of how true it is.
I'm not even a programmer but I feel like this advice extends to more fields. Anyone can figure out what something does if they're taught or can even use context clues. It's a lot harder to figure out why it's there because function may not have obvious implication. Hence a 'why' is way more valuable than a 'what'.
Anyone who reads your code now knows your thought process and the function's purpose.
This fits very well with my belief: "if you havd to write something only once, do it right"
YES!!! Comment on the reason and intent. What it does can be derived from actually readying the code. Thank you Thor!
The number of times I have written a 'why' comment and saved myself headache from having to reread my own code is super high
especialy with game that can be modded, having usefull comments is a godsend
To be fair, "This sets unbreaking to 1" as a comment for "unbreaking: 1" is like posting a sign above a door that reads "This is for going through".
That's some high levels of "No shit sherlock" right there :P
I would be honored to work on you code Sir.
PR reviews are so important for deciding where comments are needed.
I often find that pieces of code I imagined would be confusing to other devs are self explanatory to them, and if I add too many comments they will read right past them and miss the important ones
I'm getting back into programming, I haven't done it since college in 07. I probably wouldn't have of. If it weren't for you inspiring me. Originally I learned visual basic and SQL. But I found an app to learn Python on. And it feels as exciting as learning programming for the first time again.
Depends on the language, method of coding and situation. There can be bigger chunks of code that doesn't make sense to put in a function. So it's useful to write a comment describing what the following block does.
"Why" is useful when it's obvious what the code does.
Okay, this is actually so much more helpful than being taught to just type out what it does.
Oh, how many times I had to explain this to "wizard style" software engineers...
Too real, man
it's about why being more important than the what, it's about the why typically being less obvious than the what. Explain what isn't obvious. Are you literally ust assigning a value to a variable? The why is going to be less obvious. Are you checking if the players health is still positive after being attacked? The why is self explanatory, but the what might still be worth documenting. I for sure agree that the why is typically what is more important, but it's more complicated than just "document why, not what"
Programming equivalent of "Never mind, fixed it myself."
This is actually pretty helpful. I will now promptly ignore it because listening means rewriting hundreds of comments because i went for the "quantity over quality" route.
I think this kinda thing should be also be known even for conversations. A great example is telling kids, "because I said so" or "because I'm your parent," saying that doesn't teach reasoning.
As I sit here, nearly midnight, mere days after I thought to myself that I want to learn how to work in s&box (and godot sometime but that's a whole other wheelhouse) I am glad to see this. I may have a small amount of programming in my background but having good comments eluded me
I did a stint as a programmer before changing paths to become an Art Therapist. When working with code the number of times I wish there was reasoning behind the old code rather than just useless comments was uncountable. It really made it hard to know when adding or changing anything if it was also somehow changing other important things without knowing because the code wasn't well documented or in some cases with the really old code, just so inefficiently written.
I think adding a "why" to a lot of things is very important because everyone likes to know the reason why something is the way it is.
Comments should never explain what code does, because if someone can't just read it and understand what it does then it's bad code. 100% agree that comments should be about why that code was necessary.
This sets unbreaking to 1
This is a s**t comment.
My favourite is the meme
"junior devs be like"
And it was a picture of a stop sign with a arrpw pointing to it saying "this is a stop sogn"
OMG i literally say this to my students every year. don't comment 'what', comment 'why'. good to see other people in the industry have similar views
From someone learning how to code from scratch, thank you. Very few instruction courses really anywhere state anything like this even though one would think it's common sense to do this. Yea, I'm serious.
Thor: "We put why its there, not what it does"
My comments: "This is here as without it, the code doesn't work, I have no idea what it does"
At my job, my team has a rule of no comments. The purpose is to force us to write meaningful names for everything, and promote encapsulation whenever possible.
This philosophy has been working quite well on our projects. I know it's not "one size fits all", though.
“This sets unbreaking to 1”
“This tree is an aspen. We know that it’s an aspen because of the way it is”
“what” can be important to if the way the code itself works is unclear, but usually in that case you should just rewrite the code to be more clear
In most cases, type b is backed by source control. You can click on a line and see its commit message. It's less error prone and less verbose, and only fails if anyone manages to erase all relations to source control. In that sense, for most modern devs its perfectly okay to not comment in code.
Type one was what we were told to do at uni. On my first job, I wanted to make the best impression and made sure to put them *everywhere*. Nobody cared until, two years later, we needed to share the code with our partners. Wouldn't be surprised if some of that is still there
You know what.... as I think about it really... I'll get started tomorrow and rewrite my comments. Thanks for the advice.👍
I cant remember who the creator was but back when i was coding basic menus for campaign GTA V, I used someones menu that they uploaded as a learning document and i swear to god, every single unique line of code was explained.
From "this line sets the key that is used to open the menu" to "this line uses r,g,b values to set the colour for all slider bars. Only takes effect if previous line is set to 0".
It was a coding noobie's wet dream 😂
Me, an intellectual, “ah yes. There are 2 types of comments. Single line and multi line.”
"This is set to unbreakable because, for whatever reason, it deletes a random item when used otherwise."
Yeah good point...
...if we could understand the "why" of code ourselves
As a brand new programmer, who also just saw the Necro thread post, I feel like there is an oppurtunity here for a joke between these two shorts that could be VERY funny.
"Yes, this causes a Memory Leak. Too bad!"
"This is bad dumb code but more importantly it's bad dumb code that does nothing. Why? Did it ever?"
"My hope with this code is that I am never allowed to work on GUI ever again."
I also love variable with a name that is the value, ie: FLAG_P = "P" instead of giving the variable name a meaning like FLAG_PROCESSED = "P".
Lukewarm take: If you need to explain what your code does in a comment, it’s time to refactor
"The spell works. I dont know why if tampered with the machine will die Please leave it be kind regards exausted tech wizard"
"-- If you remove this section I will haunt your soul for eternity."
Was in a script I co-wrote with a colleague.
That's funny, we're taught to make comments the wrong way (although, our codes can sometimes be messy AF).
Code: what
Comments: why
Documentation: how
Thor just flexed his experience on us all. 99% of you are guilty and you know it!! 😂
My favorite comment is "I do not know what this does but when I take it away everything goes to shit."
@@DavBotsArcade “when writing code only programmer and god knows what the code does. Few weeks later only god knows” this is the truest wisdom anyone has ever said about software development.
Professor's: "what i dont know what your talking about, this is clearly fake."
Sometimes the "what it's doing" comments are nice when you're summarizing the function of a big block of code.
I've been doing this actually, but mostly because I forget how or why I used certain code, so I over-explain things to my self so I know future me will understand it.
I feel like explaining what it does us important for more complicated bits of logic or whatever too
Remember profs hounding people for comments in homework, thought it was stupid. Now I’m real world (and working on 13 year old code), I believe no comments should be automatic failure for an assignment.
I work at a bank and I wish people would apply this to when they leave holds and comments on accounts. I don't want you to write "hard hold" I want to know WHY. Or god forbid they put "Ask favorite animal" when there are 3 people on the account and the answer isn't even in our system!!!!
Code should be as self discriptive as possible. This is usually done with good discriptive variable/class/type/function names. It is also done by programming to the affirmative if possible (and some other good patterns). Comments should only be used to describe the reasoning behind something, if it is not apparent. (Or automation designed to look at comments like an doc generator).
So here's what I've learned:
Bad comment: This is a video on comments
Good comment: I should make more useful and non-redundant comments on things, because that will make my comments more useful and non-redundant.
Wait, I think I did it wrong...
thor literally teaching me better than my college lecturers
"they're both the same picture" 😂