What I've learned from programming and heard from many senior level programmer is to never document WHAT your code does - rather document the WHY. Like, WHY did you solve it like this? Is there a reason WHY you store the data in this form? WHY do we even need this? This in combination with good method names really helps a lot
imho whats worth mentioning here is when you refactor like this dont just assume it works like it did before, especially if youre not the only one working on the code. As a developer my dad has many a horror story about how an overconfident dev was like "wow this code bad right here i can write better code" without checking with anyone or making it clear enough that they changed anything, and suddenly everything is broken and nobody knows why. even for code that is 100% me, maybe im just dumb but theres countless times where i go to refactor even the simplest thing in my own code and it just stops working because i forgot something little or messed up my syntax and honestly, im not sure how i feel about just automatically deleting "zombie code" or "redundant" comments. as with most things in code it depends - the example youve given definitely seems to warrant the cleanup. I think that every time you see something like this its worth considering whether its still serving any purpose. Maybe as i gain confidence and skill as a developer I'll become more comfortable with the idea of comments like these having to go, but right now it makes me uncomfortable. I've found that I always need to comment my code like I take notes for a math class - which means i need act like im talking to a literal brick. It not only helps me think about the code as I write it, but also greatly helps me rebuild my working mental model of, basically, how i think about my code, whenever I pick up where i left off. Sometimes my comments probably look redundant to others, but my brain just needs to see something written in a color that isnt the color of the code. Much like I wouldnt want someone to just say "you dont need this" and throw away half my math notes, I wouldnt want someone to do that to my probably seemingly redundant comments. If i dont need them anymore, I will know and remove them. I've worked with uncommented code in an sdk that was very descriptive of the intent but it didnt fully work. we tried fixing it but the code structure leaned so heavily into "describing intent" that the actual logic was so abstracted that it was nearly impossible to follow. the method calls were seemingly *endlessly* nested and when you finally reached the last one you still had no idea how the code actually functioned. after days of this and zero progress we decided that we would be better off foregoing the sdk entirely, immediately everything got much smoother. in a similar manner, the zombie logic i leave also usually serves a purpose to me. if its not gone i probably am still using it, if for no reason other than to use as a checklist as i write the new logic. and while it is in source control, by deleting you could be forcing someone to have to spend time hunting around source control in the future. tl;dr; a badly worded way of saying i really cant see myself irl being as carefree with deleting comments as you were in this video, im too afraid of throwing away someone's notes.
I really like the idea and in fact I was already doing similar things in my code, but I don't think this is enough to avoid using comments as a whole. Also, comments have been very useful for me, as thanks to them I've been able to create documentation websites using only doxygen and no aditional work, as it reads the comments and converts them to clear documentation.That said, encapsulating conditions and other similar functions is really nice, more if they're something you'll need to use more than once, but using them to substitute all of the code willl generate a lot of code just for properties, which I think could be a problem if you need to change those properties at some moment. So my position is, use this to reduce the complexity of code and the reliance of comments but find a balance so that you can keep at least comments for the methods and such. And yeah, keep your code clean and write selfexplaining names for variables, methods and all of that.
This is extremely helpful. I always knew that we should use variables instead of hardcode value for maintainability if we need to change something but I never thought of using varibles purely for readability. That makes SO MUCH SENSE
I want someone like Charles to review my code! The problem with not working in a company is you don't have a senior checking your code, then you end up with a mess in your code and you have to learn it the hard way!
Haha I wish I had the time to review everyone's code, too xD but you're totally right, having someone else look over your code and provide feedback is incredibly valuable.
Up until now I wondered why I've seen so much code that appeared to be wasting time declaring variables that didn't seem to need to be declared. You explained this so well that now I FINALLY understand it, and I thank you! Also... oh noes! Poor Charles! I hope Barles doesn't have to 'delete' him!
I've been pushing for this sort of change at my work place. Currently we have strict rules about commenting everything that results in comments on getter methods like: /* * gets X */ public int getX(){} etc Meanwhile X might be an actual variable name that does not correspond to an x co-ordinate and takes 10 minutes of reading through the code to figure out. One counter point to the sort of self-documenting code you suggest though, performance. I know that 99% of the time there is no real performance hit for all these method calls, but I have talked to people working in AAA games that have told me they have tons or duplicated, inline code in their engine because the overhead of function calls is too much to maintain 60fps when added up over the whole project. So these people rely heavily on comments to explain algorithms etc that would be better encapsulated in a method call. When working on less demanding games, or on enterprise software though, I definitely prefer to have clearer code and remove the comments.
Interesting topic and good video! Reminds me of some parts in the book "Clean Code" by Robert C Martin. There is also the notion that other team members often won't update comments when a method is changed and that methods and variable names should be self explanatory in an effort to reduce the need for comments as much as possible. I think I should revisit the book someday since my memories of the concepts are already a bit fuzzy, but it is a good read. Having methods for small checks that have a verbose name is also mentioned to be a good idea.
It's a great eye opener. I was aware of the problem, but not really knew exactly how to solve it nicely. Just extract everything you can into lambda type properties, that i love so much.
After reading comments for this video: Some tips for people who really wants extract all code parts to different methods for better understanding: Extract all code that you dont cleary understand in very big project, also do it with every frequently called code => slow down your program. Check this out: simple inline calculation vs method call(with same calculation inside) results for 1 million calls: Inline: 10,6802 mills MethodCall: 29,5754 mills Results are same but execution time(perforamance) different. Inline 3 times faster. You can do same test. If you really want to understand some code parts when you back to it, just use #region instead of move all code to whole method and consume you cpu time(imagine it runs on slow mobile cpu, not on pc) Next tip. If you are team lead or just you development team consists of 3+ programmers and some of them can be changed over time, then you obviously need ready to use documentation(website, generated from xml comments in code) for your team. That will makes some processes run faster. Next tip. If you don't want see a lot of comments in your code, you can move docs in different files and link it via xml special tag using just one comment line Last tip. Computer dont do the magic, everything has a price. Remember that
I do recommend proper naming conventions for methods, steer away from the "for each" traps. Strong commented code creates ease for people from different disciplines especially at times when refactoring is a thing. Additionally, creating accessible information that doesn't require you to go into the code is A+.
Great examples of how to document code easily. Also big + for the comedy in this one. I like to write function names that are descriptive and reduces the need for comments aswell. Sometimes the method names get a bit long though.
Nice entertaining, it makes sense but definitely a bit hard for Junior Developers like me, but it make sense and it something I should start learning from my early steps.
The funny thing Is I just spent the last hour removing "Zombie Code" from my Business partner's class... and found this video in my subscription feed :)
Dude i really like the PT-BR comment once i understand and laught a lot hahahahah and great video, please keep comming with this great content please :D
Thank you so much for this! Your videos helped me incredibly much in learning how to write good code. I hope you're okay and will upload again in the future :)!
What is your opinion on using Unity tooltip attributes? It has an advantage of seeing extra information without needing to swap between code and unity, but also have all the cons you bring in this video.
not gonna lie, this changed my mind about trying to do this when it is applicable. i still rather comment first, and delete it later tho. better to delete a comment, than avoid them.
Making readable code is great, trying to adapt to the existing code structure too, but comments don't hurt. Just some on top of the class to describe its purpose and how to use it, some code sections titles. Some descriptions of what functions return for or where events are fired or listened... because not everyone has the same capacity to make explicit names and events are a pain to track. When you come on a big project with a lot of existing code, the usual psychopath dev. team that doesn't speak and no documentation or comments, you know you are in for a good time.
man this video is amazing, I love the suspense and the cliff hanger and the general story telling way of teaching ideas. This is definitely how school in the future will look like
Hahahaha yeah, of course the last comment had to be in Portuguese, and it's full of crazy and creep stuff in there lol Great job Charles, your vids are awesome and funny too.
@@InfallibleCode It's hilarious man, amazing! A cool fact is that, since years ago, when I was still in university I noticed that actually creating ways to visualize explanations or create triggers like this, helps a lot understanding and ultimately not forgetting about it later.
I have to tell this every time a new junior dev comes to my team. First pull request usually gets rejected due to comments everywhere. Might as well give them link to this video. One of the worst case I've seen: (In a class called Customer): // Address of a customer private String address; // Is customer active private boolean active; And so on. It was so cluttered I barely could tell how many fields there are, and all of it by useless comments.
Hey, have a question about zombie code you might be able to answer. Sometimes when I'm working on Unity scripts, I find comments of functions like in the video just appearing usually in latin, sometimes in cuniform, sometimes I don't know the character set. Whenever I try to delete it though, the window changes to a live video of a dark ethereal kind outdoors place, I hear screaming in the distance, and an eldritch creature comes up to the camera and shakes his head 'no'. Any ideas on fixes? Thanks!
I look at this pattern of development as creating macros that expose the state of your class to itself. If any other part that class needed to know whether or not the player could jump, it would now have a quick reference!
I been wondering "despite of typing comments, have I read them again and/or understood them properly if I read? there must be better way than typing comments". Thank you. it will reduces my questionable commenting
Only document your code when you are going to output generated documentation in HTML for external consumption. For everything else, stick to descriptive names.
Well i am an indie game dev. Sometimes i implement new cool features/logic in a game but decide to scrap it for this game. i dont scrap it or comment it, just put it in a different functions/class and dont call them in current project.
Zombie code has its uses 1. It reminds you what you have already tried 2. It can be a fallback if much later you find your new solution has a bug. I usually create a #region called history , and pack the zombie code in there, inside current context. I do not hesitate to delete Zombie code that am sure will never be referred to , usually means everything working tested happy ages ago. But without leaving a trail of solutions, for some complex stuff, you could be going round in circles not knowing what you already tried. Zombie code does deserve its own place, and its no problem in neat tidy code. I am not a supporter of this idea that you only need to make a point once in code. Make your intention clear with code, then say the same thing again in your comment, leaving the reader in no doubt as to your intention. Hence why am am very much against auto in c++ and var in C#, code is faster to write , takes much longer to understand. There is a reason why aviation industry worships redundancy in design. Coding does not come naturally to anybody especially on a bad day, that's what repeating yourself and comments are for. They are not for when the going is good. 777 can fly just fine on one engine, but it has 2. If you ever try to stabilise comms between 5G network chip via uart interface on a hard real time system, you'll know what Zombie code is for.
Hmm looking at Microsoft's documentation now. Maybe "auto-property" isn't the correct terminology, after all. I'm seeing "getter-only property" -> docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/properties
Zombie code :) Not heard it called that before :) I've got a couple of zombie classes, lol. Source control isn't always the best place for unfinished stuff though.
@@InfallibleCode maybe that's worth a try - never really left myself notes in the code, more this almost works remind me to finish it later. Zombification.
why are you using properties and auto properties for something you could just use fields for? Just using standard private/public fields would even be more performant?
Hi Charles / infallible code. I have a question regarding some of the code and that is with the =>, is this a way of showing a pointer to a statement ? The reason for bringing this up is I am trying to figure out what the equivalent would be in C++ Visual Studio as I am writing a game engine in C++ / Visual studio, during my spare time to build a game development portfolio.
I sometimes rewrite my methods, hence have zombie code, just in case my new method version doesn't work or is worse. But once i decited for one of these, I delete the other
I never developed with JetBrain Products but what are the "simple enough" annotations in ur code? Does they count the characters and lines or something in the methods to hint a potential refactor?
As a game programmer, we ultimately aim for fast execution in a game loop. When you start to do optimizations like this, you risk slowing execution by adding function call overhead and breaking away from thinking in a CPU context for fast execution. If you move your code too high level, then you loose low level speed benefits.
I recommend you look into the compiling process, how automatic inlining and lowering works. Not only does the compiler drastically change your code automatically but deciding against using tools to make code more maintainable and scalable for "fast execution" you end up with projects that are hard to maintain and find bugs in. I would happily trade a few ms in my primary game loop for less cyberpunk 2077s. Glorifying performance without a nuanced understanding of pareto principle optimisations and technical depth costs is the cause of a lot of the problems with "game programmer" culture.
You will be surprised that compiler does tons of optimization for you. Making a few code for readability is much better than optimization. Also premature optimization is bad, don't do it.
👕 Check out my merch store at teespring.com/stores/infallible-code-merch
What I've learned from programming and heard from many senior level programmer is to never document WHAT your code does - rather document the WHY. Like, WHY did you solve it like this? Is there a reason WHY you store the data in this form? WHY do we even need this?
This in combination with good method names really helps a lot
this was both informative AND entertaining, a very rare combo in code tutorials
One of the only channels whose videos I always watch because I always learn something new. Thank you, Charles, your videos are extremely valuable.
I'm so glad to hear that! Thank you :D
imho whats worth mentioning here is when you refactor like this dont just assume it works like it did before, especially if youre not the only one working on the code. As a developer my dad has many a horror story about how an overconfident dev was like "wow this code bad right here i can write better code" without checking with anyone or making it clear enough that they changed anything, and suddenly everything is broken and nobody knows why.
even for code that is 100% me, maybe im just dumb but theres countless times where i go to refactor even the simplest thing in my own code and it just stops working because i forgot something little or messed up my syntax
and honestly, im not sure how i feel about just automatically deleting "zombie code" or "redundant" comments. as with most things in code it depends - the example youve given definitely seems to warrant the cleanup. I think that every time you see something like this its worth considering whether its still serving any purpose. Maybe as i gain confidence and skill as a developer I'll become more comfortable with the idea of comments like these having to go, but right now it makes me uncomfortable.
I've found that I always need to comment my code like I take notes for a math class - which means i need act like im talking to a literal brick. It not only helps me think about the code as I write it, but also greatly helps me rebuild my working mental model of, basically, how i think about my code, whenever I pick up where i left off. Sometimes my comments probably look redundant to others, but my brain just needs to see something written in a color that isnt the color of the code. Much like I wouldnt want someone to just say "you dont need this" and throw away half my math notes, I wouldnt want someone to do that to my probably seemingly redundant comments. If i dont need them anymore, I will know and remove them.
I've worked with uncommented code in an sdk that was very descriptive of the intent but it didnt fully work. we tried fixing it but the code structure leaned so heavily into "describing intent" that the actual logic was so abstracted that it was nearly impossible to follow. the method calls were seemingly *endlessly* nested and when you finally reached the last one you still had no idea how the code actually functioned. after days of this and zero progress we decided that we would be better off foregoing the sdk entirely, immediately everything got much smoother.
in a similar manner, the zombie logic i leave also usually serves a purpose to me. if its not gone i probably am still using it, if for no reason other than to use as a checklist as i write the new logic. and while it is in source control, by deleting you could be forcing someone to have to spend time hunting around source control in the future.
tl;dr; a badly worded way of saying i really cant see myself irl being as carefree with deleting comments as you were in this video, im too afraid of throwing away someone's notes.
I really like the idea and in fact I was already doing similar things in my code, but I don't think this is enough to avoid using comments as a whole. Also, comments have been very useful for me, as thanks to them I've been able to create documentation websites using only doxygen and no aditional work, as it reads the comments and converts them to clear documentation.That said, encapsulating conditions and other similar functions is really nice, more if they're something you'll need to use more than once, but using them to substitute all of the code willl generate a lot of code just for properties, which I think could be a problem if you need to change those properties at some moment. So my position is, use this to reduce the complexity of code and the reliance of comments but find a balance so that you can keep at least comments for the methods and such.
And yeah, keep your code clean and write selfexplaining names for variables, methods and all of that.
This is extremely helpful. I always knew that we should use variables instead of hardcode value for maintainability if we need to change something but I never thought of using varibles purely for readability. That makes SO MUCH SENSE
I want someone like Charles to review my code!
The problem with not working in a company is you don't have a senior checking your code, then you end up with a mess in your code and you have to learn it the hard way!
Haha I wish I had the time to review everyone's code, too xD but you're totally right, having someone else look over your code and provide feedback is incredibly valuable.
Up until now I wondered why I've seen so much code that appeared to be wasting time declaring variables that didn't seem to need to be declared. You explained this so well that now I FINALLY understand it, and I thank you! Also... oh noes! Poor Charles! I hope Barles doesn't have to 'delete' him!
I've been pushing for this sort of change at my work place. Currently we have strict rules about commenting everything that results in comments on getter methods like:
/*
* gets X
*/
public int getX(){}
etc
Meanwhile X might be an actual variable name that does not correspond to an x co-ordinate and takes 10 minutes of reading through the code to figure out.
One counter point to the sort of self-documenting code you suggest though, performance. I know that 99% of the time there is no real performance hit for all these method calls, but I have talked to people working in AAA games that have told me they have tons or duplicated, inline code in their engine because the overhead of function calls is too much to maintain 60fps when added up over the whole project. So these people rely heavily on comments to explain algorithms etc that would be better encapsulated in a method call. When working on less demanding games, or on enterprise software though, I definitely prefer to have clearer code and remove the comments.
Interesting topic and good video! Reminds me of some parts in the book "Clean Code" by Robert C Martin. There is also the notion that other team members often won't update comments when a method is changed and that methods and variable names should be self explanatory in an effort to reduce the need for comments as much as possible. I think I should revisit the book someday since my memories of the concepts are already a bit fuzzy, but it is a good read. Having methods for small checks that have a verbose name is also mentioned to be a good idea.
Clean Code is a great book that should definitely be on every programmer's shelf. Your comments makes me want to read it again!
This video reminded me of that book too, I'm currently reading it in free time
It's a great eye opener. I was aware of the problem, but not really knew exactly how to solve it nicely. Just extract everything you can into lambda type properties, that i love so much.
After reading comments for this video:
Some tips for people who really wants extract all code parts to different methods for better understanding:
Extract all code that you dont cleary understand in very big project, also do it with every frequently called code => slow down your program.
Check this out: simple inline calculation vs method call(with same calculation inside) results for 1 million calls:
Inline: 10,6802 mills
MethodCall: 29,5754 mills
Results are same but execution time(perforamance) different. Inline 3 times faster. You can do same test.
If you really want to understand some code parts when you back to it, just use #region instead of move all code to whole method and consume you cpu time(imagine it runs on slow mobile cpu, not on pc)
Next tip. If you are team lead or just you development team consists of 3+ programmers and some of them can be changed over time, then you obviously need ready to use documentation(website, generated from xml comments in code) for your team. That will makes some processes run faster.
Next tip. If you don't want see a lot of comments in your code, you can move docs in different files and link it via xml special tag using just one comment line
Last tip. Computer dont do the magic, everything has a price. Remember that
I do recommend proper naming conventions for methods, steer away from the "for each" traps. Strong commented code creates ease for people from different disciplines especially at times when refactoring is a thing. Additionally, creating accessible information that doesn't require you to go into the code is A+.
i was just about to comment my entire code base (small). thanks. love the content style and your speach. subscribed.💙
Only you could write a code talk with a Halloween theme and still make perfect sense xD
Hahaha this is my favorite comment xD
Wow, I'm a linguist and it's the best explanation why I was so irritated by someone's else code.
Awesome video! Great production quality as always, that Halloween part was great.
Thanks!
Your example is very good, useful. Especially the property getter expressions.
infallible code socially distances from himself somehow
You can never be too safe 😉
Great examples of how to document code easily. Also big + for the comedy in this one.
I like to write function names that are descriptive and reduces the need for comments aswell. Sometimes the method names get a bit long though.
Acting, Teaching and Comedy, you are very good at many things. I learned many things from this video. Nice concept of content and tutorial.
If you need help remembering what zombie code is, just remember 1- they are the undead and 2- they look green (well in most cases)
Lol, nice Halloween reference!
haha thanks
Fantastic video! Learning to write self documenting code is super key for any dev. I am a big advocate of it and barely use comments.
I just realize I tent to do this kinda and dont leave so many comments, just titles to some things in functions, cool!
Nice entertaining, it makes sense but definitely a bit hard for Junior Developers like me, but it make sense and it something I should start learning from my early steps.
This is a good video, this channel is very underrated.
The funny thing Is I just spent the last hour removing "Zombie Code" from my Business partner's class... and found this video in my subscription feed :)
Hah good timing xD
Spooky.
Love this idea 👍. Gonna try it on my project.
Good job on the zombie concept 😁
I lost it with namespace Redrum xDD
Too good bro👍👍👍 the concept is very understandable love from India
Appreciate it! Sending love from the US 🙌
Love the format and pretty informative too 👏 keep up 😎 Looks like I'm going to delete some zombie code in my project too
Your videos are a gift. I appreciate you!
Thank you for the kind words!
Dude i really like the PT-BR comment once i understand and laught a lot hahahahah and great video, please keep comming with this great content please :D
Morri junto
Lambda expressions are awesome!
Right? That's definitely one of my favorite features of the language.
Ace vid.
I’m converted. I often leave code commented out thinking I may find it useful in future.
Actually very informative. Thanks
Also, sick rig bro 🤙
Thank you so much for this! Your videos helped me incredibly much in learning how to write good code. I hope you're okay and will upload again in the future :)!
A horror episode of a programming tutorial... Well, that's new. I love it! 😀
Amazing video! One of the most informative on comments i've ever seen!
This video was amazing, entertaining and informative :D
Fantastic. Great use of Socratic Dialogue!
man, i always learn a lot with your videos, thank you.
You are awesome :D
What is your opinion on using Unity tooltip attributes? It has an advantage of seeing extra information without needing to swap between code and unity, but also have all the cons you bring in this video.
Nice video!, very useful!
May be it's just me stupid, but took me more than half of video time to get Halloween reference!
haha nice
not gonna lie, this changed my mind about trying to do this when it is applicable. i still rather comment first, and delete it later tho. better to delete a comment, than avoid them.
This gave me chills! Great video, really helpful too :)
4:28 > this is not a less than. _weight > 100 would mean if the _weight is greater than 100.
That error only shows how clarifying the encapsulation was.
Thats what we need!
I appreciate it :D
Making readable code is great, trying to adapt to the existing code structure too, but comments don't hurt.
Just some on top of the class to describe its purpose and how to use it, some code sections titles. Some descriptions of what functions return for or where events are fired or listened... because not everyone has the same capacity to make explicit names and events are a pain to track.
When you come on a big project with a lot of existing code, the usual psychopath dev. team that doesn't speak and no documentation or comments, you know you are in for a good time.
Another invaluable video. Thank You!
Clean code fellings here.
man this video is amazing, I love the suspense and the cliff hanger and the general story telling way of teaching ideas. This is definitely how school in the future will look like
This was super entertaining, fun and edicational :) Love the video
Hahahaha yeah, of course the last comment had to be in Portuguese, and it's full of crazy and creep stuff in there lol
Great job Charles, your vids are awesome and funny too.
haha glad you enjoyed it! :D
@@InfallibleCode It's hilarious man, amazing!
A cool fact is that, since years ago, when I was still in university I noticed that actually creating ways to visualize explanations or create triggers like this, helps a lot understanding and ultimately not forgetting about it later.
😆 NIce. I kind of caught on early, but it is still good.
I have to tell this every time a new junior dev comes to my team. First pull request usually gets rejected due to comments everywhere. Might as well give them link to this video.
One of the worst case I've seen: (In a class called Customer):
// Address of a customer
private String address;
// Is customer active
private boolean active;
And so on. It was so cluttered I barely could tell how many fields there are, and all of it by useless comments.
Once again thanks for the great video
This was very helpful
Am i only one that have those same youtube recommendations as Barles? Lol
haha those are some great recommendations xD
I see DevDuck in the background 👀
Hey, have a question about zombie code you might be able to answer. Sometimes when I'm working on Unity scripts, I find comments of functions like in the video just appearing usually in latin, sometimes in cuniform, sometimes I don't know the character set. Whenever I try to delete it though, the window changes to a live video of a dark ethereal kind outdoors place, I hear screaming in the distance, and an eldritch creature comes up to the camera and shakes his head 'no'. Any ideas on fixes? Thanks!
might not be the focus of the episode but 1) why refactor into auto properties and 2) why expression bodies?
I look at this pattern of development as creating macros that expose the state of your class to itself. If any other part that class needed to know whether or not the player could jump, it would now have a quick reference!
@@InfallibleCode thanks for the response! Already started doing this. I have comments all over the place and it's time for a change! :D
Nice! :D
Best tutorial ever!
I been wondering "despite of typing comments, have I read them again and/or understood them properly if I read? there must be better way than typing comments". Thank you. it will reduces my questionable commenting
Only document your code when you are going to output generated documentation in HTML for external consumption. For everything else, stick to descriptive names.
Good video! Btw, you did not encapsulate isGrounded and the other method.
To my future self, start watching from 3:48
Well i am an indie game dev. Sometimes i implement new cool features/logic in a game but decide to scrap it for this game. i dont scrap it or comment it, just put it in a different functions/class and dont call them in current project.
what's the "simple enough" % thing over functions?
It’s a plug-in for Rider that displayed the cyclomatic complexity of your functions plugins.jetbrains.com/plugin/10395-cyclomaticcomplexity
@@InfallibleCode thanks
Zombie code has its uses
1. It reminds you what you have already tried
2. It can be a fallback if much later you find your new solution has a bug.
I usually create a #region called history , and pack the zombie code in there, inside current context.
I do not hesitate to delete Zombie code that am sure will never be referred to , usually means everything working tested happy ages ago.
But without leaving a trail of solutions, for some complex stuff, you could be going round in circles not knowing what you already tried.
Zombie code does deserve its own place, and its no problem in neat tidy code.
I am not a supporter of this idea that you only need to make a point once in code.
Make your intention clear with code, then say the same thing again in your comment, leaving the reader in no doubt as to your intention.
Hence why am am very much against auto in c++ and var in C#, code is faster to write , takes much longer to understand.
There is a reason why aviation industry worships redundancy in design.
Coding does not come naturally to anybody especially on a bad day, that's what repeating yourself and comments are for. They are not for when the going is good.
777 can fly just fine on one engine, but it has 2.
If you ever try to stabilise comms between 5G network chip via uart interface on a hard real time system, you'll know what Zombie code is for.
In this case, this is code from a repo so the zombie code still existed in previous versions of the program.
does this take up more memory, because it uses global variables?
5:30 Why do you call it auto properties? Auto properties are { get; set; }
This is an auto-property with an expression body getter.
Hmm looking at Microsoft's documentation now. Maybe "auto-property" isn't the correct terminology, after all. I'm seeing "getter-only property" -> docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/properties
It's Lamda expression though
That keyboard use at 7:30 is ghastly.
lol! What's wrong with it?
@@InfallibleCode
Both hands.
One finger peck.
Another finger peck.
For ctrl + s.
Merely two keys away
from each other.
The home row misses you.
5:48 Just found the expression bodies!
Is your IDE converting C# Lambda => into the actual unicode rightwards double arrow symbol "⇒" ?
Zombie code :)
Not heard it called that before :)
I've got a couple of zombie classes, lol. Source control isn't always the best place for unfinished stuff though.
I like to occasionally leave TODO comments because most modern IDEs recognize them and have dedicated TODO windows.
@@InfallibleCode maybe that's worth a try - never really left myself notes in the code, more this almost works remind me to finish it later. Zombification.
XD good to know about zombie code!
why are you using properties and auto properties for something you could just use fields for? Just using standard private/public fields would even be more performant?
Hi Charles / infallible code.
I have a question regarding some of the code and that is with the =>, is this a way of showing a pointer to a statement ? The reason for bringing this up is I am trying to figure out what the equivalent would be in C++ Visual Studio as I am writing a game engine in C++ / Visual studio, during my spare time to build a game development portfolio.
Great video!
I get back to some parts of my code after months, and weeks. Useful comments do exist.
Hey, that comment at 6:53 is in portuguese, are you portuguese or something?
Nah I'm actually half-Cuban. The earlier comment is in Spanish :P
I've paused the video to read it all, not gonna lie.
The text looks like the automated translation of random english sentences taken from horror stories (or just generated to look like that)
I sometimes rewrite my methods, hence have zombie code, just in case my new method version doesn't work or is worse. But once i decited for one of these, I delete the other
I never developed with JetBrain Products but what are the "simple enough" annotations in ur code? Does they count the characters and lines or something in the methods to hint a potential refactor?
That "simple enough" annotation actually comes from a plugin called "Cyclomatic Complexity" plugins.jetbrains.com/plugin/10395-cyclomaticcomplexity
@@InfallibleCode thanks! There is plugin for VSCode too. Looks promising.
As a game programmer, we ultimately aim for fast execution in a game loop. When you start to do optimizations like this, you risk slowing execution by adding function call overhead and breaking away from thinking in a CPU context for fast execution. If you move your code too high level, then you loose low level speed benefits.
I recommend you look into the compiling process, how automatic inlining and lowering works.
Not only does the compiler drastically change your code automatically but deciding against using tools to make code more maintainable and scalable for "fast execution" you end up with projects that are hard to maintain and find bugs in.
I would happily trade a few ms in my primary game loop for less cyberpunk 2077s. Glorifying performance without a nuanced understanding of pareto principle optimisations and technical depth costs is the cause of a lot of the problems with "game programmer" culture.
You will be surprised that compiler does tons of optimization for you. Making a few code for readability is much better than optimization.
Also premature optimization is bad, don't do it.
Have you got a surge protector?
Yup! That's why Barles' computer stayed on xD
Thanks, what's your font using in this IDE?
The real horror of this episode is when that guy in the ad shouts "STOP WHAT YOU ARE DOING...." :)
Horrifying 😱
Fuuuuu.... love this channel! Great class.
Expression bodies look interesting, do you have any videos on them and their pros and cons?
it's literally just a different syntax, easier on the eyes, and you have to press a couple less buttons
You know encapsulating code adds a small (almost negligible amount of overhead), but greater than 0 overhead
No I do what I want!
6:56 it's just random "evil" words in portuguese lol
Amazing work , gold mmmm !
DevDuck in the background!
I was looking for your channel for month but i forgot your name.
sick pc! where'd u get it from?
Honestly I would make assets for the Unity Asset Store but they want you to have your code commented.