For this weeks blogpost, I will be talking about a podcast that I listened to about Clean Code. Clean Code is a book written by Uncle Bob, who has his own blog websites and talks about all different topics of Clean Coding. In this book it is by him, but each section will include thoughts and ideas from other people who helped create the book. This podcast was again talked about by my favorite Comp. Science podcast group so far, Coding Blocks. This podcast they specifically talk about meaningful names and what the book says about them, and their thoughts on them. Some of the stuff I agreed with and others not so much. So the first thing brought up about clean code is the Two door idea. One door you open has clean code with only two WTF’s while the other door holds bad code inside of it with a lot of WTF’s. The first door is WTF in a good way, like WTF this is bad, while the second door uses WTF in a bad way, like WTF is this and WTF is that. After that they speak about their own thoughts on the Clean Code book They go through different sections like liked and even bring up their own experiences of coding in the beginning of their careers up to now. After that their first code that they liked was brought up, “If a name reviews a comment, then that name does not reveal its content”. I found this pretty cool for a number of reasons. One, because I had always viewed comments as good since it explains what the code is doing and can help the user reading the code. Two, because my professor had just mentioned this quote in class, which I found pretty ironic was the first quote I heard about in the first podcast about Clean Code. Naming your variables can reveal the entire purpose though and can avoid disinformation. For example, if you name something that has the word list in it, and it doesn’t have anything to do with making a list, then that name doesn’t convey what it actually does. To go along with that example, remember to not use programming terms if it is not actually that. For the most park longer names do trump shorter names, but the links to the variable names should directly correlate to its scope. Small variable names in small block scopes and larger scope that that variable is available, the longer the name. The next thing they talked about was the HUngarian Notation. The Hungarian Notation doesn’t prepend STR to available C++/ Old C programs or basics. Hungarian Notation is if you have a string name, it would b sN or a binary integer it would be bIisValid and that’s how you knew what the type was. This left problems though if someone changed the type and would leave the variable name. So you would have this bIisVariable and it was not a boolean or an integer. Hungarian Notation used to be valued but once it got multi lettered ones. It was especially hard when you had a long class name and you use the first letter as an abbreviation, you wouldn’t even know what that type is. It was simple for short primitive types back in the day and it couldn’t be done with today's editors. It is also important to be names pronounceable. If they are pronounceable, it’ll be easier to explain to someone else. So, when you do nested loops with short names, you have to mentally map things out and if you have to do that your code is going to break down. If the scope is small, it is okay. One thing they did mention that they had never thought about was that class names should be nouns and method names should be verbs. After this, the Factory Design Pattern was talked about and how it helps when constructors are overloaded. Everything talked about there was talked about sometime in class and I pretty much knew, so I will not go in depth about that topic. Lastly, they mentioned two quotes which I really liked. One was, that the ‘hardest thing about choosing good names is that it rewrites good descriptive skills and a shared cultural background. The two hardest things about naming is that it can be off by a one error and cache invalidation. Naming is huge and hard. You have to be analytical and descriptive. This brings me to my second quote, “Rename things that don’t make sense when working in your code is good”. So when you see a bug, fix it. A lot of really good points that i heard about were mentioned that I didn’t talk about with this blogpost. I definitely recommend anyone to listen since naming is such an important part of coding. I was really excited to listen to this podcast since I think Clean COde is a really important aspect anyone can gain from coding. It helps others and yourself when programming. I would really like to use a lot of these tips in the future on my code myself so when I am working with others, it will make the process go a lot smoother for all of us.
