This is one of the longest and most information dense videos I've put out in quite a while so I'd love to hear your thoughts on it. Leave me a comment and let me know if the video and the examples helped you out.
The second thumbs down - YAGNI - is equivalent to don't think ahead and plan for flexibility and changing requirements. This is another huge failure of cookie-cutter devs that gets them fired from my teams.
I agree with everything except the commenting thing. Everyone who tells me that their code is "self-describing," I usually cannot read that code. It is usually terrible. People who comment a lot, I have noticed also follow the other best practices because, they care A LOT about readability
Ditto, was about to post. Not commenting is terrible advice. But I'd just add to not comment what the code obviously already does. Comment to describe the thinking and structure around the code. Divide the algorithm up into sections. Describe anything that's unusual and not readily apparent from the code. Describe where the function fits in, and what larger task it's intended to be called from. The mark of good code is how fast you can get into state. Some of our legacy code is incredibly bad (written by people no longer on the team), and it takes an hour of untangling all the needless structure-theatre and bad variable names. Our good code is well-explained, and we're usually back into state in a few minutes. The comments serve as a narrator/babysitter to understand the thinking behind the code. This also helps bug fixing, because you have an abstract of what the code is intended to do, and then the bug is apparent. I will no longer tolerate code that isn't well-explained so that I can get into state immediately.
Hey Andy, really great content! Although I‘m no beginner by any means. Watching you explain principles and you being so relatable in your videos made my day! ❤️ Maybe a video on Unit testing and common patterns would help junior devs to be more keen on this topic
I did enjoy this set of 5 rules because they solidify how I write except w/t comments. I now understand your point of how comments can get in the way or be harmful and if the previous 4 rules are followed, then #5 is easy to understand. I learned a lot with this video and will start now getting them into my rhythm of writing.
The best thing about variables is that size of the name doesn't matter at runtime. Before you compile the code, sure, the longer name takes up space, but once compiled, the size of your variable name is irrelevant to the code. For comments, I typically use them to break up the code visually, more of a roadmap than necessary information. For instance, I might group all of my Public Methods under one comment and Private Methods under another. Totally spot on about descriptive functions and variables though. I remember working on a project getting my degree in graphic art/game art, and trying to help fix a program that wasn't working. Spent a half day trying to figure out what the variable "s" was used for; turned out, nothing at all relevant to anything going on. I think it was an unimplemented speed parameter, but as the guy coming in after someone else coded, I had to work that out for myself.
i actually went back through some of my code and was like yep that function has a noun and not a verb as a name. lol very helpful because as a begin you don't know the correct way to do all the things until someone point it out. it like speaking or writing another language there are just some formal things that need to happen. thanks for the video
Some of these suggestions I've kind of picked up during my studies or intuited, but I definitely appreciated the confirmation that my thought process was on the right track! I'll renew my focus on keeping my code more readable.
One of your best videos, very concise and helpful. Would like to see more videos like this with advices and practices in programming, maybe some project walktrough :)
Okay so I understand both sides of the comments vs. no comments argument. I would like to see a video of appropriate times for a comment. I also think its a ridiculous premise to fire an individual for not commenting. If you have a complicated app that you feel the dev should add comments to then instruct them to do just that. Andy I see and agree with its a more practical approach to rename variables and functions that essential tell you what they do for the app. Thank you for your efforts and instruction. I myself have just decided to reorganize my life to attempt to be a programmer after a 9 year set back.
I agree! Name your variables properly will help. It has caused so many headaches for other people reading my code. Wished if I had this advice a few months ago😥. Thanks, Andy - keep at it this was helpful👨💻
isMilitaryTime does make even less sense to at least a non US audience, as normal time is 24h and 12h is just US time. The fact that twentyFour is a boolean made is meaning clear, though not sufficiently explicit. Apart from the example, the point is very valid.
copy&paste from stackoverflow: The idea behind "self-documenting" code is that the actual program logic in the code is trivially clear enough to explain to anyone reading the code not only what the code is doing but why it is doing it. In my opinion, the idea of true self-documenting code is a myth. The code can tell you the logic behind what is happening, but it can't explain why it is being done a certain way, particularly if there is more than one way to solve a problem. For that reason alone it can never replace well commented code. .
Very small downside to short functions is that function calls might not be free (depending on the compiler/interpreter) and might introduce slowdowns when called millions of times in a loop. I see many people write functions with a single line of code as the body of the function... In my opinion that should not even be a function.
Exactly my point. Building and breaking down stack frames is not free - far from it. But it is a consequence of people thinking that they have so much horse power under the hood that it doesn't matter. That's why I still like a preprocessor to be part of my stack. You can wrap small functions into a macro, so they get inlined. I also pointed out elsewhere that the whole clock wrapping (including 24/12 toggle) could be put in a single statement (hour = isMilTime ? ((hour + 11)%12) + 1 : hour % 24;) and the whole isMilTime toggle could be expressed like "isMilTime = !IsMilTime". No need to make a function like that. I'd write it like: #define ToggleMilTime(a) (a)=(!(a)) Same readability, no need for a function.
(4:05) I'd like to mention that while this is not a Unity project, some IDEs have required function names and "Update() { }" happens to be one of those functions where if you change the name it will break your whole project. The same with "Start() {}". (15:18) In case anyone needs it (in C#): public static int sumOfAll (int[] inputArray) { int sumToReturn = 0; foreach (int thisOne in inputArray) { sumToReturn += thisOne; } return sumToReturn; }
Yes, absolutely, I am the type of person who benefits from explicit examples, so I found this format to be extremely helpful. Even though I haven't learned any JS (not yet, but soon), the code was easy to follow as a student of Python and C. Thanks for the tips!
All useful tips, thanks! Particularly find that descriptive variable and function naming makes code just flow so much more naturally, both during writing and for later readability!
I have a python background so looking at the example of the function that was doing all those things my first thought was put that function into a class and break-up all that functionality into modules. That could offer more flexibility in terms of adjusting the module maybe, adding or subtracting things inside the module. Just a thought.
Hello Andy. Thanks for your imformative and clear video. Although most of the points I new before, It is nice the hear them a from a professional. I write programs for myself, but I am not a professional developer. In addintion, I have some easy questions to ask: 1. Which font did you use in the code of your demonstration? I like it. 2. I guess you use Visual studio, me too. I managed to change colors to most important object, but could not find, where to change Background and font color for Menu, Properties and solution explorer windows. Thanks for your help and all the best. Moshe.
While it's true that one doesn't need to (and probably shouldn't) comment every single LOC, I find comments really useful when working in teams or with big projects. You'll come across the other people's code quite often. They write functions, import libraries, and make database calls that will yield results that you might use in your part. It's just impractical to log all the db call results, read the docs of libs that you won't be directly using, or read though the entire function every single time. If your colleagues are nice enough to write some comments about thier funcs (what it takes and what it will return and in what format and data type), it will make your life a lot easier. Without them you'll probably have to figure it out yourself or give them a call if you're WFH.
Thank you for a few very good advices! I admit that I still fall into couple of these in my projects (namely the naming and overcommenting) These are great pointers for starters, though I do disagree in comments in couple of things... First off, I love comments when planning in the code editor. I often add the functions/methods I know I'll need and simply use comments to write the functionality in pseudo code or simple few word lines. These won't be saved in the final function, but offer a great way to plan ahead how each function works. Secondly, I wish to bring out editor related assistants (like Javadoc style comments and summary tags in C#, for example) when creating larger projects or libraries. While it's true what you said about the importance to update these when the functions/methods are updated, it's a great tool when you and the other devs are using the same IDE or editor with IntelliSense or similar as these do provide tool tips for the user. Of course these two examples are related to workflow and larger projects for maintenance, not for people just getting into coding or doing some smaller project that can easily be read if the function, method, variable names can be used instead. I'd also wish to bring out the namespaces as a solution (or extra challenge) for the naming concept. Namespaces are a great tool for larger projects and commonly left along for smaller ones. The naming of namespaces takes an extra step from naming variables, functions and methods as these are one new world - in a sense. Lastly, I'd encourage people who start to learn how to code or try to start their careers as devs, to pay some time to learn how to plan their projects. There are many ways to do this and the easiest is pen&paper (just as we used to D&D in the past *smirks*) - I'd suggest familiarizing yourself with concepts like: - learning class and sequence diagrams with UML - roadmaps and milestones - Scrum/Agile/DevOps Personally, I like planning with comments in the source code for smaller projects, doing UML for larger ones and tracking the project and it's process with tools like Trello or Jira.
When I saw variable twentyFour I instantly knew what it was trying to accomplish. If I would saw isMilitaryTime variable, I would think wtf is military time?
Agreed I would name it "isTwentyFourHoursTimeFormat" No joke you end up naming the variables in german format with long sentences or you know just add good comments to help you identify everything including a first paragraph of text comment that explains everything like a journal. Sadly this is the only way to retain information once you finished the code.
Good. Bad advice before 2 minutes in. Good others are correcting the nonsense. Is12hourTime() or useAmPm() suggest time format uses silly USA-only system. Functions should be understandable by international programmers. Datetime should use a format (or language-country indicator) not a collection of functions. This is as bad as have NameFirst and NameLast fields instead of NameFull, NameLegal, and NameShort fields. Think ahead. Think. When creating function signatures, the next morning, try to use the function without looking. Then fix the signature to match what you expected it to be.
@@solprovider5385 And yet, you understood what he was trying to convey. The example was to get you to think of an appropriate naming convention for your variables. Personally, I have yet to work for an international team, and wouldn't waste two seconds researching NameFull, NameLegal, and NameShort, because it would make no sense the the US developers working on it. Not every team outsources internationally. But, if you are working on an international team, that makes sense. I would simply counter that as a good programmer, you should be taking into account everyone involved. Of course, I'm a programmer who believes the end user should have input on the functionality of the product being developed, which occasionally makes me odd-man-out when it comes to programming. ;)
@@nyghtwyng I am American. I understood because beginner mistakes are common. Tutorial videos should teach good development, not replace worst mistakes with barely better mistakes. You do not need an international team to have NameFirst and NameLast cause problems with Indian, Hispanic, and even European names. - A large American company HR entered an Indian name 3 ways creating 3 records, corrected by deleting one and terminating another. Years later, the employee still had paychecks disappear. - Same company had Vincent Peter LastName III who preferred Pete and rarely used suffix. Medical insurance system failed to match his name and assumed he was no longer employed. Business has input into functionality. Business should not decide implementation. Every software development team needs one Great Solution Architect to avoid mistakes.
Connect classnames to filenames also each class have many files obviously. Also Nullcheck gives restrictions to class variable creation other than _(private signifier) make sure to initialize all variables with standard. Then add functions to reinitialize. Always create objects explicitly (due to null safety but also neat to have intent in code have object dot!) Camel non camel is good for variables. Split code in different categories and make them be as self contained as possible. Use simplified programming like always do if then with {} and stick to it as far as possible don't use shortcuts just simple code gets the job done and is simpler to read no surprises ok?! and many more rules to make the code uniform and simple as possible to read. I have project been rewriting it last 6month almost no new features just better structure... Great tips great video!
That was a roller coaster, a devastating one, first of all twentyFour is perfectly understandable in a clock project context, it's also perfectly recognizable as a time format in any other context besides in America, changing it to isMilitaryTime not only makes it unrecognizable for people who don't know what military time is, it makes it unrecognizable for the rest of the world. That is an argument not only for the initial rename, but for the fact that names can always be ambiguous. Next, the main/update function, a function of such a generic name is always destined to do multiple things and you can't expect it not to, you ended up changing it's name to renderDate which didn't describe what it was doing so you fixed your own problem by extracting all that is not renderDate from it and moving it to the now new main function that is anonymous gaining an additional layer of nesting in the process. Now, why anonymous? Hello, it doesn't have a name and setInterval certainly doesn't describe what it is doing, it's also doing multiple things, huh? Wouldn't that mean that anonymous functions shouldn't exist according to these guidelines, because to me it definitely would. And lastly, comments, the problem with then in the given project was not the comments themselves, it's that it was overpopulated with them. When there is a lot of comments there is no doubt the descriptive quality of them will go down, it will also go down when you drastically change the function it's describing like you did with the update function. Yeah, comments that focus on something become outdated over time as the subject of focus changes, but really shouldn't they? They are needed when you want to read some piece of legacy code, maybe even your own after 3 months to get a more clear idea of what a thing is or what it does, which level proper naming typically can't reach, of course they are gonna get dated if you directly change what they are describing. The point of this rant is that clean code is inconsistent because all code is inconsistent. Stick to what you understand best or what you agreed to stick to if you are working in a team, because such vague standarts won't live up to the standarts, to the conrete ones.
I've seen people name a function or an object method that returns a string, a number, a boolean, or any other non-function values with nouns or with verbs. Both ways seem reasonable. Curious about what's your take on this?
Hmm... since when is "toString" a verb? Also, writing very short methods tends to lead to the creation of a lot of methods that hardly do anything. Trust me: while debugging, the last thing you want is to hop between zillions of tiny methods that add nothing to the clarity of the code. Structure is key here. I would also like to introduce a sixth rule: Take as much time as you can and think things through. Don't fall for the myth of the programmer who is "ten times faster." I often have to deal with code written by such so-called super-programmers and find myself rewriting most of it because it tends to be a mess. I can especially tell when a programmer is an Uncle Bob worshiper, because I find myself merging methods together to make the code more readable.
Personally I don't know what is meant by military time and standard time for me is the 24 hour format, so I'd prefer twentyFour over isMilitaryTime. So at the moment you renamed the variable to isMilitaryTime it made sense to you, but if someone else comes there it may not make complete sense.
There's always the risk that it will happen and for many variable names it is just inevitable that it will happen. The idea behind it is to spend some time and think through it so that it reduces the risk of confusing yourself and others in the future. You can always change the name later on after thinking about a more specific name but at the end of the day there are no perfect variable names.
@@AndySterkowitz I would have used an enum named something like "TimeDisplayFormat" that had two choices: "standard" and "military" or if those two names don't help clarify, the values could be "twentyFourHour" and "twelveHour"
@@purduetom90 if there were more than 2 states of the clock then I would agree. In this case since there are two states of the clock then a boolean is a clean solution IMO. Appreciate you sharing this!
Functions is not always a verb though or sometimes it is hard to come up with a name. If not a verb much better to say the output of the function as a name or something.
yeh my code is crazy. post bootcamp react, deprecated everything lol 3 different ways of styling and random stitched together hooks. but it works!! kinda ha
Don't call it "military time". Call it "twenty-four-hour time". "Military time" refers to saying "fifteen hundred" instead of "fifteen o'clock". I'd call the variable "isTwentyFourHour", and I had no trouble figuring out what "twentyFour=false" in a clock program is supposed to mean.
Superb explanation but comes with experience. Also, the download kept failing on me. I don't know if someone else has a similar Problem downloading your Material.
Everything said was true until the comments section, I think comments are good for freelancers, most of the time when I go back to my code sometimes it helps! But as Andy said, sometimes it's disturbing, I change the code and then I should change the comments too 😅
In my CS classes, variables where names foo and ba, and the lecturers also used a and b. I think our Physics classes and text books had better story telling than CS books and classes. Maybe CS books and lecturers could bring more story in their lessons and begin to help with better variable names.
Actually TwentyFour is probably better than isMilitaryTime because outside of the USA we won't necessarily know what Military Time is. Better to have renamed it isTwentyFourHourClock because now you have a name that means the same thing to everyone.
Hello Everyone! I am an Industrial Engineer but i would really like to change to programming, but the town i Live in Portugal does not have much Jobs available. Do you think someone with no experience can land a job? Even if it starts as an unpaid internship?
Hypothetically if I have a function that is inside or a module is it acceptable in your opinion to allow that module to assist in the shortening of the name? For example “./controllers/thingBeingControlled” “function get() function del()” I’m realizing it would then be more self documenting to call it with Module.get() than just with get()
Great video, just some thoughts : 1) th-cam.com/video/qBedDXc1fUc/w-d-xo.html timeFormatToggle is enough i think, but may be if this variable is best omitted and chain called if not used anywhere else. 2) th-cam.com/video/qBedDXc1fUc/w-d-xo.html toggleTimeFormat(); or alterTimeFormat();.
I want to be a developer but it's difficult for me to be in class especially as a Deaf student when things are going much much faster, I just want something I can do at slow pace so I can practice and become better. I'm comfortable with HTML+CSS already, I just want to dip my feet in JS and possibly NodeJS, any tips?
I disagree with your stance on comments. Comments should be used to explain why something is done a certain way. Developers need to document their code more not less. Think about how frustrating it is to ise a library without documentation.
A comment that is only just pseudo code of the following code is not only useless, it can be harmful. Whenever someone modify the code, there is a risk of unsyncing the code and its comment. It can unsync as far as meaning the exact inverse. In think that we should not comment how the code works, cause the code explains it by itself, but instead we must comment to explain the big picture: The reason for the existance of that code.
Hey Andy, can you airdrop me some of your knowledge for me been a new subscriber to your page or let's say 'in-particularly', ME? Lol. You're a really good teacher on this one. I started watching your video about 5-4 hours ago and i have been getting some wisdom, understanding what to it takes to be a programmer. Thank you for your time to make me understand that.... Your Subscriber. Dare {3ch0}
That's a fair point! On dev teams we have discussions like this all the time and if someone brings up a point like this I'd be open to changing my mind.
The NEED for math in programming is a myth. Obviously it depends what the job is, but you can totally do programming while not being that good at math :)
Experience is dogmatic rules often are barking mad. 15 line function limit is often too short for clarity and can make things harder to read at times. Long list of closely-related checks or initialization? Often more readable in longer functions. Composition root is an excellent example where it makes sense to go longer. Also, depending on context, error handling is easier in longer linear functions. A refinement may be: avoid nested lengthy functions as they’re prone to getting even harder to read than shorter nested functions. Sometimes even 3 levels deep (3D-related code) is easier to understand with all the levels visible at once, as an example.
isMilitaryTime makes no sense. As that might be your regional term. As a Indian developer, I can make more sense on twentyFour or isTwentyFourHour. That's it, after that 2.15 minutes into your video and I stopped watching it. Many developers might not know what the hell is military time, due to their regional language barrier.
I think you need a little more info about comments. Comments are useful to explain thinking, not function. You might use a sub optimal solution for a good reason - a useful comment would explain the thinking and save the next person going through the thought process. I
1. twentyfour was unclear. But I would have renamend it to use24hourTimeformat or something like this. Because military time no one uses here! We use always 24h ! We use meter, kilogramms, celsius and 24h. Military time may be at 4:45 when we shoot back while invading poland ... to write is in front of a bool variable ist fucking hungarian notation. I though we overcame this after annying MFC m_ stuff. and its even worse because sometime you'll have a getter with this Name. This getter would than be calles isIsMilitaryTime ... 2. naming methods a verb is often a good idea. But a method average() is as clear as calcAverage() 3. a function should do one thing an do it well. Ok. But NOT to call a lot of smaller functions and to on to have a debug hell. Better to have a function with 1000 of code than. A new sub-function introduce a dependency. Especially when you one day think "hey I have this little function i can resuse it". Can be good. Sometimes its not. And what about performance. If you iterate over soething and have all the imformation, also from backend rest api or database in hand, why not do an necessary addtional thing in this main loop then? A method can do more than one thing at a time. It can do 2 or 3. You only should give it a descriptive name and write a comment about possibel side effects. 4. comments should explain why something is done. If i look at your code and need more than 5 mins to understand it: than a comment is missing. I can read code. But I want to read the code, not to reengineer it! Look at your own code from 10 years ago. Do you have any question or problem to understand it? Than comments are missing or code is bad. 5. Dont use cuddled else expecially when using intendation of 2. So that the else and the if block and else block melt optically together to a code block. An else belongs in the same columns as the if! So it was in all languages the standard until Sun and Adobe (suprisingly they use this uglyness also in their SDKs) come along. Cuddles else is bad style. Period. No wonder clean code advocates recomment only a few nestest ifs and other loops. I understand it: in your style its not readable. I can easitly read nested flow structures of 10 and more. And you need that for image processing. E.g. appling a filter matrix to and RGB-image. You need the loops over x and y and i and j, you need the ifs to check ranges, you need it for 3 or 4 color channels. Format the code well. Also: if you break a line and if-statement than write curly brackets! Even if it is one statement. But start with uncuddling the else.
This is one of the longest and most information dense videos I've put out in quite a while so I'd love to hear your thoughts on it. Leave me a comment and let me know if the video and the examples helped you out.
It shows. Really solid advices, we appreciate it!
Thumbs down - comments are king. I fire developers from my team for being terrible at documenting their own code.
The second thumbs down - YAGNI - is equivalent to don't think ahead and plan for flexibility and changing requirements. This is another huge failure of cookie-cutter devs that gets them fired from my teams.
Very good and useful video. Well worth the longer-than-usual duration. 😀👌
@@guitarman813 thanks!
Take a look at some of Google's open source code. Some of their variables are complete sentences.
Love that!! :-)
I agree with everything except the commenting thing. Everyone who tells me that their code is "self-describing," I usually cannot read that code. It is usually terrible. People who comment a lot, I have noticed also follow the other best practices because, they care A LOT about readability
Ditto, was about to post. Not commenting is terrible advice. But I'd just add to not comment what the code obviously already does. Comment to describe the thinking and structure around the code. Divide the algorithm up into sections. Describe anything that's unusual and not readily apparent from the code. Describe where the function fits in, and what larger task it's intended to be called from. The mark of good code is how fast you can get into state. Some of our legacy code is incredibly bad (written by people no longer on the team), and it takes an hour of untangling all the needless structure-theatre and bad variable names. Our good code is well-explained, and we're usually back into state in a few minutes. The comments serve as a narrator/babysitter to understand the thinking behind the code. This also helps bug fixing, because you have an abstract of what the code is intended to do, and then the bug is apparent. I will no longer tolerate code that isn't well-explained so that I can get into state immediately.
Hey Andy, really great content! Although I‘m no beginner by any means. Watching you explain principles and you being so relatable in your videos made my day! ❤️ Maybe a video on Unit testing and common patterns would help junior devs to be more keen on this topic
Thanks, will do!
Another vote for unit testing!
I did enjoy this set of 5 rules because they solidify how I write except w/t comments. I now understand your point of how comments can get in the way or be harmful and if the previous 4 rules are followed, then #5 is easy to understand. I learned a lot with this video and will start now getting them into my rhythm of writing.
The best thing about variables is that size of the name doesn't matter at runtime. Before you compile the code, sure, the longer name takes up space, but once compiled, the size of your variable name is irrelevant to the code.
For comments, I typically use them to break up the code visually, more of a roadmap than necessary information. For instance, I might group all of my Public Methods under one comment and Private Methods under another.
Totally spot on about descriptive functions and variables though. I remember working on a project getting my degree in graphic art/game art, and trying to help fix a program that wasn't working. Spent a half day trying to figure out what the variable "s" was used for; turned out, nothing at all relevant to anything going on. I think it was an unimplemented speed parameter, but as the guy coming in after someone else coded, I had to work that out for myself.
This is really informative and helpful. Appreciate the examples!
i actually went back through some of my code and was like yep that function has a noun and not a verb as a name. lol very helpful because as a begin you don't know the correct way to do all the things until someone point it out. it like speaking or writing another language there are just some formal things that need to happen. thanks for the video
Some of these suggestions I've kind of picked up during my studies or intuited, but I definitely appreciated the confirmation that my thought process was on the right track! I'll renew my focus on keeping my code more readable.
One of your best videos, very concise and helpful. Would like to see more videos like this with advices and practices in programming, maybe some project walktrough :)
Okay so I understand both sides of the comments vs. no comments argument. I would like to see a video of appropriate times for a comment. I also think its a ridiculous premise to fire an individual for not commenting. If you have a complicated app that you feel the dev should add comments to then instruct them to do just that. Andy I see and agree with its a more practical approach to rename variables and functions that essential tell you what they do for the app. Thank you for your efforts and instruction. I myself have just decided to reorganize my life to attempt to be a programmer after a 9 year set back.
I agree! Name your variables properly will help. It has caused so many headaches for other people reading my code. Wished if I had this advice a few months ago😥. Thanks, Andy - keep at it this was helpful👨💻
Really great video. Thanks broski
Fantastic video! Thank you very much for putting in the time to make these.
isMilitaryTime does make even less sense to at least a non US audience, as normal time is 24h and 12h is just US time. The fact that twentyFour is a boolean made is meaning clear, though not sufficiently explicit. Apart from the example, the point is very valid.
Clean code is a good book to read for more like this.
These rules are classic. With the right procedure names and variable names, your code becomes self documenting.
copy&paste from stackoverflow:
The idea behind "self-documenting" code is that the actual program logic in the code is trivially clear enough to explain to anyone reading the code not only what the code is doing but why it is doing it.
In my opinion, the idea of true self-documenting code is a myth. The code can tell you the logic behind what is happening, but it can't explain why it is being done a certain way, particularly if there is more than one way to solve a problem. For that reason alone it can never replace well commented code. .
Very small downside to short functions is that function calls might not be free (depending on the compiler/interpreter) and might introduce slowdowns when called millions of times in a loop. I see many people write functions with a single line of code as the body of the function... In my opinion that should not even be a function.
Exactly my point. Building and breaking down stack frames is not free - far from it. But it is a consequence of people thinking that they have so much horse power under the hood that it doesn't matter. That's why I still like a preprocessor to be part of my stack. You can wrap small functions into a macro, so they get inlined. I also pointed out elsewhere that the whole clock wrapping (including 24/12 toggle) could be put in a single statement (hour = isMilTime ? ((hour + 11)%12) + 1 : hour % 24;) and the whole isMilTime toggle could be expressed like "isMilTime = !IsMilTime". No need to make a function like that. I'd write it like:
#define ToggleMilTime(a) (a)=(!(a))
Same readability, no need for a function.
i love those kind of videos, keep them up man :)
Thanks Mohamed...will keep it in mind!
10:38 "mon is that for 'hey mon'?" 😂
twentyFour as a boolean made perfect sense to me instantly, I have no idea what military time is...
make it “isTwentyFour” at least
Yes sir, going into my Junior year and I read the book Clean Code this summer. Definitely aligns well with a lot if not all of the points.
(4:05) I'd like to mention that while this is not a Unity project, some IDEs have required function names and "Update() { }" happens to be one of those functions where if you change the name it will break your whole project. The same with "Start() {}".
(15:18) In case anyone needs it (in C#): public static int sumOfAll (int[] inputArray) { int sumToReturn = 0; foreach (int thisOne in inputArray) { sumToReturn += thisOne; } return sumToReturn; }
Yes, absolutely, I am the type of person who benefits from explicit examples, so I found this format to be extremely helpful. Even though I haven't learned any JS (not yet, but soon), the code was easy to follow as a student of Python and C. Thanks for the tips!
All useful tips, thanks! Particularly find that descriptive variable and function naming makes code just flow so much more naturally, both during writing and for later readability!
This was actually pretty useful, thx :D
I have a python background so looking at the example of the function that was doing all those things my first thought was put that function into a class and break-up all that functionality into modules. That could offer more flexibility in terms of adjusting the module maybe, adding or subtracting things inside the module. Just a thought.
Hello Andy. Thanks for your imformative and clear video. Although most of the points I new before, It is nice the hear them a from a professional. I write programs for myself, but I am not a professional developer. In addintion, I have some easy questions to ask: 1. Which font did you use in the code of your demonstration? I like it. 2. I guess you use Visual studio, me too. I managed to change colors to most important object, but could not find, where to change Background and font color for Menu, Properties and solution explorer windows.
Thanks for your help and all the best. Moshe.
Great video!!! Thanks!
While it's true that one doesn't need to (and probably shouldn't) comment every single LOC, I find comments really useful when working in teams or with big projects. You'll come across the other people's code quite often. They write functions, import libraries, and make database calls that will yield results that you might use in your part. It's just impractical to log all the db call results, read the docs of libs that you won't be directly using, or read though the entire function every single time. If your colleagues are nice enough to write some comments about thier funcs (what it takes and what it will return and in what format and data type), it will make your life a lot easier. Without them you'll probably have to figure it out yourself or give them a call if you're WFH.
twentyFour tells me a lot more than military time. But I agree with your concept to use clear, telling names even if they tend to be long. 2:07
Thank you for a few very good advices! I admit that I still fall into couple of these in my projects (namely the naming and overcommenting)
These are great pointers for starters, though I do disagree in comments in couple of things...
First off, I love comments when planning in the code editor. I often add the functions/methods I know I'll need and simply use comments to write the functionality in pseudo code or simple few word lines. These won't be saved in the final function, but offer a great way to plan ahead how each function works.
Secondly, I wish to bring out editor related assistants (like Javadoc style comments and summary tags in C#, for example) when creating larger projects or libraries. While it's true what you said about the importance to update these when the functions/methods are updated, it's a great tool when you and the other devs are using the same IDE or editor with IntelliSense or similar as these do provide tool tips for the user.
Of course these two examples are related to workflow and larger projects for maintenance, not for people just getting into coding or doing some smaller project that can easily be read if the function, method, variable names can be used instead.
I'd also wish to bring out the namespaces as a solution (or extra challenge) for the naming concept. Namespaces are a great tool for larger projects and commonly left along for smaller ones. The naming of namespaces takes an extra step from naming variables, functions and methods as these are one new world - in a sense.
Lastly, I'd encourage people who start to learn how to code or try to start their careers as devs, to pay some time to learn how to plan their projects. There are many ways to do this and the easiest is pen&paper (just as we used to D&D in the past *smirks*) - I'd suggest familiarizing yourself with concepts like:
- learning class and sequence diagrams with UML
- roadmaps and milestones
- Scrum/Agile/DevOps
Personally, I like planning with comments in the source code for smaller projects, doing UML for larger ones and tracking the project and it's process with tools like Trello or Jira.
More of this!
The order is year, month, day, hour, minute, second. If someone wants it in day/month/year order, set a flag as you did for 24-hour time.
Thank You
When I saw variable twentyFour I instantly knew what it was trying to accomplish. If I would saw isMilitaryTime variable, I would think wtf is military time?
Military time is when you click the button it deploys the military :). American colloquial lingo...24 hour clock rest of the world.
Agreed I would name it "isTwentyFourHoursTimeFormat"
No joke you end up naming the variables in german format with long sentences or you know just add good comments to help you identify everything including a first paragraph of text comment that explains everything like a journal.
Sadly this is the only way to retain information once you finished the code.
Good. Bad advice before 2 minutes in. Good others are correcting the nonsense. Is12hourTime() or useAmPm() suggest time format uses silly USA-only system. Functions should be understandable by international programmers. Datetime should use a format (or language-country indicator) not a collection of functions.
This is as bad as have NameFirst and NameLast fields instead of NameFull, NameLegal, and NameShort fields. Think ahead. Think.
When creating function signatures, the next morning, try to use the function without looking. Then fix the signature to match what you expected it to be.
@@solprovider5385 And yet, you understood what he was trying to convey. The example was to get you to think of an appropriate naming convention for your variables. Personally, I have yet to work for an international team, and wouldn't waste two seconds researching NameFull, NameLegal, and NameShort, because it would make no sense the the US developers working on it. Not every team outsources internationally. But, if you are working on an international team, that makes sense.
I would simply counter that as a good programmer, you should be taking into account everyone involved. Of course, I'm a programmer who believes the end user should have input on the functionality of the product being developed, which occasionally makes me odd-man-out when it comes to programming. ;)
@@nyghtwyng I am American. I understood because beginner mistakes are common. Tutorial videos should teach good development, not replace worst mistakes with barely better mistakes.
You do not need an international team to have NameFirst and NameLast cause problems with Indian, Hispanic, and even European names.
- A large American company HR entered an Indian name 3 ways creating 3 records, corrected by deleting one and terminating another. Years later, the employee still had paychecks disappear.
- Same company had Vincent Peter LastName III who preferred Pete and rarely used suffix. Medical insurance system failed to match his name and assumed he was no longer employed.
Business has input into functionality. Business should not decide implementation. Every software development team needs one Great Solution Architect to avoid mistakes.
I really like this video, but I think a little terminology would go a long way: semantic naming, command pattern, etc.
Connect classnames to filenames also each class have many files obviously. Also Nullcheck gives restrictions to class variable creation other than _(private signifier) make sure to initialize all variables with standard. Then add functions to reinitialize. Always create objects explicitly (due to null safety but also neat to have intent in code have object dot!) Camel non camel is good for variables. Split code in different categories and make them be as self contained as possible. Use simplified programming like always do if then with {} and stick to it as far as possible don't use shortcuts just simple code gets the job done and is simpler to read no surprises ok?! and many more rules to make the code uniform and simple as possible to read. I have project been rewriting it last 6month almost no new features just better structure... Great tips great video!
Good stuff in this video. I'll take to heart the advice on comments
Same :)
That was a roller coaster, a devastating one, first of all
twentyFour is perfectly understandable in a clock project context, it's also perfectly recognizable as a time format in any other context besides in America, changing it to isMilitaryTime not only makes it unrecognizable for people who don't know what military time is, it makes it unrecognizable for the rest of the world. That is an argument not only for the initial rename, but for the fact that names can always be ambiguous.
Next, the main/update function, a function of such a generic name is always destined to do multiple things and you can't expect it not to, you ended up changing it's name to renderDate which didn't describe what it was doing so you fixed your own problem by extracting all that is not renderDate from it and moving it to the now new main function that is anonymous gaining an additional layer of nesting in the process. Now, why anonymous? Hello, it doesn't have a name and setInterval certainly doesn't describe what it is doing, it's also doing multiple things, huh? Wouldn't that mean that anonymous functions shouldn't exist according to these guidelines, because to me it definitely would.
And lastly, comments, the problem with then in the given project was not the comments themselves, it's that it was overpopulated with them. When there is a lot of comments there is no doubt the descriptive quality of them will go down, it will also go down when you drastically change the function it's describing like you did with the update function. Yeah, comments that focus on something become outdated over time as the subject of focus changes, but really shouldn't they? They are needed when you want to read some piece of legacy code, maybe even your own after 3 months to get a more clear idea of what a thing is or what it does, which level proper naming typically can't reach, of course they are gonna get dated if you directly change what they are describing.
The point of this rant is that clean code is inconsistent because all code is inconsistent. Stick to what you understand best or what you agreed to stick to if you are working in a team, because such vague standarts won't live up to the standarts, to the conrete ones.
I've seen people name a function or an object method that returns a string, a number, a boolean, or any other non-function values with nouns or with verbs. Both ways seem reasonable. Curious about what's your take on this?
Hmm... since when is "toString" a verb?
Also, writing very short methods tends to lead to the creation of a lot of methods that hardly do anything. Trust me: while debugging, the last thing you want is to hop between zillions of tiny methods that add nothing to the clarity of the code. Structure is key here.
I would also like to introduce a sixth rule: Take as much time as you can and think things through. Don't fall for the myth of the programmer who is "ten times faster." I often have to deal with code written by such so-called super-programmers and find myself rewriting most of it because it tends to be a mess. I can especially tell when a programmer is an Uncle Bob worshiper, because I find myself merging methods together to make the code more readable.
started my first dev job three months ago and can definitely relate to most of this :D :D especially the Y.A.G.N.I. :D :D
I used to obsess over everything when I first started as well :-)
Good bless u
good shit!
Military time would have confused me, where I live no one uses am and pm
Very informative, I've learnt something here
Some good tips, and I’m guilty of breaking more than one of Andys laws lol
It happens...I probably break them from time to time to :-)
Personally I don't know what is meant by military time and standard time for me is the 24 hour format, so I'd prefer twentyFour over isMilitaryTime. So at the moment you renamed the variable to isMilitaryTime it made sense to you, but if someone else comes there it may not make complete sense.
There's always the risk that it will happen and for many variable names it is just inevitable that it will happen. The idea behind it is to spend some time and think through it so that it reduces the risk of confusing yourself and others in the future. You can always change the name later on after thinking about a more specific name but at the end of the day there are no perfect variable names.
@@AndySterkowitz I would have used an enum named something like "TimeDisplayFormat" that had two choices: "standard" and "military" or if those two names don't help clarify, the values could be "twentyFourHour" and "twelveHour"
@@purduetom90 if there were more than 2 states of the clock then I would agree. In this case since there are two states of the clock then a boolean is a clean solution IMO. Appreciate you sharing this!
These videos are so insightful.
Glad to hear that Nurul!
YAGNI - definitely need to learn that one 😅
Functions is not always a verb though or sometimes it is hard to come up with a name.
If not a verb much better to say the output of the function as a name or something.
yeh my code is crazy. post bootcamp react, deprecated everything lol
3 different ways of styling and random stitched together hooks. but it works!! kinda ha
thanks
Insightful. Thank you
Cheers!
Don't call it "military time". Call it "twenty-four-hour time". "Military time" refers to saying "fifteen hundred" instead of "fifteen o'clock". I'd call the variable "isTwentyFourHour", and I had no trouble figuring out what "twentyFour=false" in a clock program is supposed to mean.
Superb explanation but comes with experience. Also, the download kept failing on me. I don't know if someone else has a similar Problem downloading your Material.
Thanks for shredding my code! 😅
great video thank you
Everything said was true until the comments section, I think comments are good for freelancers, most of the time when I go back to my code sometimes it helps! But as Andy said, sometimes it's disturbing, I change the code and then I should change the comments too 😅
In my CS classes, variables where names foo and ba, and the lecturers also used a and b. I think our Physics classes and text books had better story telling than CS books and classes. Maybe CS books and lecturers could bring more story in their lessons and begin to help with better variable names.
This video is so good that I recommended it to coworkers.
1:55 It made sense to me instantly
I would probably name it is24
militaryToggleButton would confuse me even more seeing that we don't call it military time. A better name would be ```is_twentyFourHourSystem```
Helpful tips, thanks!
These are awesome tips, and you've articulated them very well!
It may just be me, but you seem a bit too close to the camera...?
Noted!
24 hour is not "military time", it's normal time. While AM / PM, especially things like 12:40 PM, is a "joke time".
Actually TwentyFour is probably better than isMilitaryTime because outside of the USA we won't necessarily know what Military Time is. Better to have renamed it isTwentyFourHourClock because now you have a name that means the same thing to everyone.
Hello Everyone! I am an Industrial Engineer but i would really like to change to programming, but the town i Live in Portugal does not have much Jobs available. Do you think someone with no experience can land a job? Even if it starts as an unpaid internship?
Definitely yes, Sir.
Great video
Hypothetically if I have a function that is inside or a module is it acceptable in your opinion to allow that module to assist in the shortening of the name? For example “./controllers/thingBeingControlled” “function get() function del()”
I’m realizing it would then be more self documenting to call it with Module.get() than just with get()
just give it a better name than get and del, extra characters cost nothing
Are you a full time youtuber or is this your side hustle?
Great info bro! 🤟🏼😎
Appreciate it!
Great video, just some thoughts :
1) th-cam.com/video/qBedDXc1fUc/w-d-xo.html timeFormatToggle is enough i think, but may be if this variable is best omitted and
chain called if not used anywhere else.
2) th-cam.com/video/qBedDXc1fUc/w-d-xo.html toggleTimeFormat(); or alterTimeFormat();.
Good video. Thanks mon!
Glad you liked it!
The problem are programmers or companies who don't want you to write comments but their codes are atrocious.
Sir what does the 5th Rule(Y.A.G.N.I) actually means could you explain it a little please...
You
Aint
Gonna
Need
It
I want to be a developer but it's difficult for me to be in class especially as a Deaf student when things are going much much faster, I just want something I can do at slow pace so I can practice and become better. I'm comfortable with HTML+CSS already, I just want to dip my feet in JS and possibly NodeJS, any tips?
Udemy, good courses with subtitles
Helpful
- Variable names
- Functions Should be short
- Functions should do one things
twentyFour was a better name since that's how it's called in the rest of the world
I disagree with your stance on comments. Comments should be used to explain why something is done a certain way. Developers need to document their code more not less. Think about how frustrating it is to ise a library without documentation.
A comment that is only just pseudo code of the following code is not only useless, it can be harmful. Whenever someone modify the code, there is a risk of unsyncing the code and its comment. It can unsync as far as meaning the exact inverse. In think that we should not comment how the code works, cause the code explains it by itself, but instead we must comment to explain the big picture: The reason for the existance of that code.
Hey Andy, can you airdrop me some of your knowledge for me been a new subscriber to your page or let's say 'in-particularly', ME? Lol. You're a really good teacher on this one. I started watching your video about 5-4 hours ago and i have been getting some wisdom, understanding what to it takes to be a programmer. Thank you for your time to make me understand that....
Your Subscriber.
Dare {3ch0}
I think I have made all of those mistakes this week.
I hate when people think 24 hour time only refers to military time. many countries use 24 hour time.
That's a fair point! On dev teams we have discussions like this all the time and if someone brings up a point like this I'd be open to changing my mind.
"Hey mon"
Can i Continue Programming even I'm suck at mathematics???
The NEED for math in programming is a myth. Obviously it depends what the job is, but you can totally do programming while not being that good at math :)
"If your'e a new developer, there's chances you're writing code that is sub-par/sub-optimal"
woah woah woah, now that's offensive
Is it ?
Experience is dogmatic rules often are barking mad.
15 line function limit is often too short for clarity and can make things harder to read at times.
Long list of closely-related checks or initialization? Often more readable in longer functions. Composition root is an excellent example where it makes sense to go longer. Also, depending on context, error handling is easier in longer linear functions.
A refinement may be: avoid nested lengthy functions as they’re prone to getting even harder to read than shorter nested functions.
Sometimes even 3 levels deep (3D-related code) is easier to understand with all the levels visible at once, as an example.
what is a seasoned programmer? Do they have salt in their head? Just kidding. I love the tips. It is actually what I needed to implement right now.
Actually you made it more complex in the comments section.. lol
Some of my variable names are basically sentences 😅
isMilitaryTime makes no sense. As that might be your regional term. As a Indian developer, I can make more sense on twentyFour or isTwentyFourHour. That's it, after that 2.15 minutes into your video and I stopped watching it. Many developers might not know what the hell is military time, due to their regional language barrier.
I think you need a little more info about comments. Comments are useful to explain thinking, not function.
You might use a sub optimal solution for a good reason - a useful comment would explain the thinking and save the next person going through the thought process.
I
1. twentyfour was unclear. But I would have renamend it to use24hourTimeformat or something like this. Because military time no one uses here! We use always 24h ! We use meter, kilogramms, celsius and 24h. Military time may be at 4:45 when we shoot back while invading poland ...
to write is in front of a bool variable ist fucking hungarian notation. I though we overcame this after annying MFC m_ stuff.
and its even worse because sometime you'll have a getter with this Name. This getter would than be calles isIsMilitaryTime ...
2. naming methods a verb is often a good idea. But a method average() is as clear as calcAverage()
3. a function should do one thing an do it well. Ok. But NOT to call a lot of smaller functions and to on to have a debug hell. Better to have a function with 1000 of code than.
A new sub-function introduce a dependency. Especially when you one day think "hey I have this little function i can resuse it". Can be good. Sometimes its not.
And what about performance. If you iterate over soething and have all the imformation, also from backend rest api or database in hand, why not do an necessary addtional thing in this main loop then? A method can do more than one thing at a time. It can do 2 or 3. You only should give it a descriptive name and write a comment about possibel side effects.
4. comments should explain why something is done. If i look at your code and need more than 5 mins to understand it: than a comment is missing. I can read code. But I want to read the code, not to reengineer it! Look at your own code from 10 years ago. Do you have any question or problem to understand it? Than comments are missing or code is bad.
5. Dont use cuddled else expecially when using intendation of 2. So that the else and the if block and else block melt optically together to a code block.
An else belongs in the same columns as the if! So it was in all languages the standard until Sun and Adobe (suprisingly they use this uglyness also in their SDKs) come along.
Cuddles else is bad style. Period.
No wonder clean code advocates recomment only a few nestest ifs and other loops. I understand it: in your style its not readable. I can easitly read nested flow structures of 10 and more.
And you need that for image processing. E.g. appling a filter matrix to and RGB-image. You need the loops over x and y and i and j, you need the ifs to check ranges, you need it for 3 or 4 color channels. Format the code well. Also: if you break a line and if-statement than write curly brackets! Even if it is one statement.
But start with uncuddling the else.
"this(dot)this" - regardless of never leaving the function, stop teaching/using "this"
Lol, I could understand the twentyFour straight away …
yeah, but good luck to undestand what it is without a context and not knowing it was initialized with a boolean value
soydev
First