I don't know if that's a noobie one (probably is because I am one) but think/talk about web based apps and their modularity (without frameworks). Another thing is writing code in non-optimal ways like using standard loops instead of some built-in methods created for that certain purpose. In regards of web development I'd like to hear about browser support. I know all this stuff boils down to "spaghetti" but still I think it's worth a mention. Perhaps something like testing your code before pushing into production?
Hey Andy, you have sparked me to pickup programming again, I want to learn Python, I took a class on JavaScript 8 years ago, I want to self teach myself programming, what you recommend I should do first?
Endless loops! As far as I remember from my recent workplace as automation developer, in order to wait for the application to respond, I wrote some endless loops... Didn't think of them as endless loops when writing, because assumed that somewhen the tests will continue (when they met the condition in the loop), but when coming in the morning to see the result/s of the Sanity tests, I realized that there was a system timeout and I had to re-login and continue the test/s from where they were stuck (due to the endless loop/s)... Therefore I added some VBScript "Or" conditions that prevented the loop/s from being endless... :)
01. 1:55 *Ambiguous naming:* Of variables, functions: Name them uniquely and in a way they explain.Use the variable like 'commenting'. 02. 4:49 *Magic Stings/Numbers:* If a value is repeated make it into variable/const. Replace the value with a var/const for context. 03. 6:39 *Lava Flow:* Dont make chunks of code which will make crash entire program if changed, use Git for backup. 04. 9:59 *Cut & Paste:* Dont use same code all over the place. repeated code -> refactor into modules, functions, classes -> one change of code should change everything rather than have to change the same code across different files. 05. 11:48 *Poltergeist:* Make it compact & concise and with less shortcuts/paths/references To fully understand these, watch this video
I wish copy-paste wasn't that often necessary. You work with an API that requires you, for every piece, say every GUI element it displays, or every event it handles, to obtain the context, obtain the instance of the API engine, instantiate a connector object compliant with its interface, configure it, declaring every field you never need as its respective default value explicitly, then apply the one single value you want to put in it and call the method that feeds it to the API engine. Or worse, generate an entirely new class which inherits after the API object and provides a dozen stub methods that do nothing because you don't need them, and one getter and one setter as required by the function you need. Dozens of files differing by 2-3 lines each from each other, just to satisfy API prerequisites.
My coding philosophy (which explicitly addresses the 5th point, poltergeists): "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery
Hmm . Version control doesn't really help lava flow, you need to either 1. Always stay consistent with the existing styles and technology or 2. Complete the features in the new technology and refactor the existing code to match before pushing to production..
These are all good points, but they're code smells, or just bad design or programming. An antipattern is a specific thing: a *known solution to a problem* that leads to a bad design. (See the entries on C2 and Wikipedia for more detail.)
@@daniel.watching He's self-taught. When I got my first job, my code impressed a seasoned algorithms engineer from a top school. The hiring manager thought I was a complete idiot, since I didn't know the names of various sort algorithms - even though I could show the fastest, or lowest memory way to sort any given data set, and then explain why neither of those are a good idea on a given real world project. After working with the post-doc guy, I learned a lot of the terminology. Which makes it easier to have non-technical conversations about technical topics, but hasn't really changed my code at all. It's like an engineer trying to talk to a doctor. If you know exactly how it works but don't say it in Latin, screw you. :p
I believe he's trying to say behavioural pattern rather than design pattern, but I would say your criticism is valid. It would have been much clearer to say something like bad programming habit rather than anti-pattern.
I’m 25 years into my development life, and these are seriously great anti patterns. Yes, read Uncle Bob - but what Andy has here is still a nice, concise set of things for beginners. I’ve seen senior developers violate these anti patterns! Great video I will share with a beginner friend!
Great video. I'm self taught for the last 20 years, and I wasn't really sure what "Antipattern" really meant; thanks for the clarification. Number 4 is Don't Repeat Yourself (DRY) which is very well described in The Pragmatic Programmer.
I expected the advice of keeping functions small. There was a study that found that programming errors became noticeably more likely whenever a function was longer than could fit on a developer's screen. When a function gets big enough to break that barrier, look for any kind of functionality that you could place into its own function.
Good variable names are more important the more long lived the variable. There is nothing wrong with using "I" or "N" for a loop index or a short variable name if the variable is only used in a few closely referenced lines of code.
I have something to contribute. As the worst programmer ever, this one is very important to me. Which is, don't just type type type type up a lot of code. Test it EVERY step of the way as you write it. Test every little thing as you add to it. Because what I'll do otherwise, is find there are 100 different bugs in it at the end, and debugging it is like guessing the combination of a 100 combination lock.... in other words, even if you fix a bug, your program won't work and you maybe can't be sure that the thing you just fixed was something that should be changed because what you just did didn't fix all of what was wrong with your program and maybe it should have been the first way before and you just made it worse.
@@jankomuzykant1844 this is being very pedantic but I prefer the variable on the left since it reads like that is the one that changes and you are checking for. Like in English we would say if you are over the drinking age. Not the drinking age is below you
And then realize it's for developers that have unlimited resources and no project manager pressure 😉 No, seriously. His books are great and understanding his opinions and common patterns he shows and why they make sense (to a certain extent, some things that uncle Bob mentions are definitely arguable) is important. Still, in the real world, you may not always be able to incorporate clean design decisions everywhere. Also what's considered clean is arguable. If you throw in generics everywhere just to satisfy DRY (don't repeat yourself) and then obfuscate the code with the generics and make it hard to understand for beginners may not be the best decision if you have a team of junior developers. I am a developer for over a decade now and I have seen very abstract code. The thing with code that abstracts everything nicely is that commonly only the people who designed it easily understand it.
@@jacqueskloster4085 This is a really good argument. I'm also very susceptible to writing these "beautiful" abstractions which can't even be named right 🙄
Genius! I am a self taught programmer with now 35 years experience. This is EXACTLY correct. When you are coding it is all clear in your head. So you can follow all your shorthand naming etc. 6 months later your code will look like someone else wrote it. Dont follow these rules so others can read your code, do this for your own sake so you can understand it. And do good layout of your code so its clear. Don't put multiple statements on the same line to save a carriage return. I have a party trick of identifying the location of bugs without reading the code. I scroll it super fast so it is a blur. When I see a "lump" of multi-line code, 90% chance that's where the bug is. I don't even have to know the programming language. Crappy layout = confusing code.
An exception to the long descriptive variable names is when you're writing scientific code and you're following a convention e.g. a position vector in physics is often just denoted by x. Also this helps with readability in complex expressions.
I have been teaching myself C# via Unity almost daily for the past year. I have one strong recommendation. When starting out, and learning how your codes function, take the time to build small test programs. This will deepen your understanding of the code, and how to make it work well, instead of just work. I stumbled through Unity's low level networking API to get my software working, only to have what I did hinder my progress for over 4 months. I recently built a small test system to really understand what was happening during network connections, disconnections, messages, etc. and only then did I realize I had hobbled myself months earlier. Happy to say that my programs are running twice as well as they were before, simply because I took an hour or two to make a test program. If I had done so in the beginning, I would have saved myself dozens of hours of trial and error.
As someone who is largely self taught, has a computing degree. Naming. This is a tricky one, the Code Complete book that others mentioned (an excellent book, that I recommend every developer should read, I still pick it up occasionally). Anyway, that book has a whole chapter (around 30 I believe), in naming things. The goal of code is that it is clear and concise. Sometimes just naming something x is enough, like if a function only uses/ returns one variable because the name of the function already (or should) tell what x is. Another great/ essential book is Head first design patterns. Patterns are powerful tools that can be used to solve problems without having to reinvent the wheel. A mistake beginners make is that they try to use patterns everywhere even when a pattern is a poor fit. Things like DRY are adhered to like a religion when breaking code up further only makes it harder to understand. There's often many ways to do things, with some better than others and more complicated than simply right or wrong. Last tip is to spend time learning data structures, it may not feel like much fun, but it will massively help you in the long run.
And it's a very good practice to have 'Programming Buddy', I mean to have someone to give them your programs to debug them, because sometimes we are too 'infatuated' with our creation that we can't see the shortcomings. Just like a mother who can't see their children wrongdoings. So to have coding buddy gives us the opportunity to see our code from another person perspective, which is extremely helpful to find bugs or improve our code.
Or go away from your code for.a while ... like a day or two or a week. When you return, review your code again; it will be like you are seeing it for almost the first time with fresh eyes. You will see issues that you didn't see previously.
Very nice video, congratulations. I would like to comment on the book example at around 03:10, for ambiguous names. The problem with the metaphor is that a book written with extensive vocabulary that makes you consult a dictionary frequently is GOOD, not bad. You not only enjoy the book (hopefully), but you also learn. Reading words you didn't know is positive. Ambiguous naming would rather be like an author naming all his or her characters with random strings of 20 digits, so each time something happens to someone you would have a hard time guessing who it happened to, without constantly looking up a table, and probably even confusing a character for another one, because they differ only in the 17th digit.
CLIFFS: every programmer should watch Uncle Bob Martin Clean Code Foundations Episodes 1 2 and 3! Seriously, will solve most of these "rude code" anti-patterns. TDD and make it work then Extract Function like crazy FTW!
I worked in an old C# application in which someone thought it was a good idea to use reflection to jump to methods that handled every UI state in a Web Forms app. The naming was bad, like "lb_42", and the IDE was not of any help. It just showed that there was a lot of methods without any reference. You never touch that code unless you have to rewrite the whole application! Professional software development can be such dirty work when handling legacy code that has historically lacked code conventions.
About Magic String / Numbers: Would you then agree that Javascript is badly designed? Because it is full of magic strings and numbers. E.g. window.addEventListener("click", ...) or if (response.status === 200) ...
Judging by the code I've seen most developers write, naming functions is easy. Simply choose from this list. "Setup","Init" "Build" , "Load". What should the function do? Anything you want. Extra points for performing multiple unrelated tasks and extending your function across three or more pages.
Re: magic numbers: These can be the source of some nasty bugs, especially in embedded software. Hard coded numbers for memory allocation, for example, can remain dormant for a long time until that right circumstance comes up to break the software. Don't assume that the number is "appropriate" (like 21 for drinking age) or the "right size" (as with static memory allocation). Always code for flexibility and a dynamic environment.
OTOH, don't be anal about magic numbers that are really, really self-explainatory and not likely to change over the next century. if(minute>=60){minute = 0; hour ++;} - are you seriously going to #define MINUTES_IN_AN_HOUR ?
@@sharpfang yes, because if for any reason someone wants to change the frequency of execution or something or has any other random reason to change this number, because pattern switched from minutes in an hour to hours of a day and the smart junior developer goes all like "I got this, replace all is my friend" he overwrites the other thing were the 5 dozen egg crate capacity is hardcoded. Cost you nearly nothing, especially with good IDE, and makes life so much easier. Don't be the smart junior, don't be me 15 years ago
@@patrickebert5748 So, you think that changing the frequency of execution is best achieved by changing the number of minutes in an hour. And a code that has minutes_in_an_hour=80 is a better code, and someone trying to determine why a function launches 9 times a day when it should launch 12 times will have an easier time debugging this.... because seeing if(minute >= minutes_in_an_hour){ minute=0; hour++;} will obviously make it clear the hour changes after 80 minutes...
Important clarification here. Every single programmer in the world is self-taught. The only difference is whether you had someone else evaluating the quality of you knowledge over time or you didn't. If you're good at being honest about self evaluation then self learning outside of a formal setting is feasible, otherwise you self learn inside a setting where you are subject to 3rd party evaluations of your progress. No one can learn for you.
@@MrCmon113 no it doesn't. From the dictionary: "cause (someone) to learn or understand something by example or experience." The above statement is a huge lie. No person can cause another person to understand something. Only the individual learning is able to develop understanding. A teachers role is to evaluate the level of understanding that the student has achieved and to correct any mis-learning that may have occured. The idea that a treacher can cause someone to understand something is one of the greatest lies ever told. There are more than a dozen people that I know personally who have failed to achieve what they could have in life because they believed the lie that it was the teachers role to imbue them with knowledge.
I agree with all the points here and urge people to take them seriously. However, I would not call these kinds of quality problems "antipatterns", but for example "bad programming practices". I tend to use the word "antipattern" for common patterns of bad design, as in design patterns. I think the word was popularized by the Brown et. al. book in the late 90's. The distinction between problems in design and problems in code quality is a meaningful one. For example if a variable is named 'a' and it in reality means 'username', it's a code quality issue. Refactoring to change the variable name after review is easy. But if the variable refers to an object with such widely varying responsibilities and convoluted structure, that a good name for it simply does not exist, the issue if more fundamental to the system.
One anti-pattern I often see is parallel arrays/lists where related data is stored across multiple collections instead of one type/class to hold the data and then one collection to hold each set of data.
I find myself occasionally still doing the first two. I have been trying to unlearn that habit, but it's not that easy to get rid of, especially when you just want some code down quickly before your mind starts to wander and you forget what you were doing (I have trouble staying focused for long)
Great video. I am also a self taught developer, been doing this for 40 years now. I am curious about your comment on testing in regards to lava flow. I have found that automated unit test specifically helps with this. When I am coding a new function, where an automated test is possible, I write the test first, then the function.
Another good telltale for needing a named constant is if a value is tied to a business concept that's fairly unchanging, like a company code or location ID. Thanks for sharing!
What I would like to add to ambiguous naming: Usually, the smaller the scope of the variable, the less specific the name has to be. In a for loop, it is totally okay to call the counter "i" instead of "index". As well, if a method is called "getCustomerList", you do not need to call the variable you return "customerList", "result" would be specific enough because the function name already says what the result is. Or if you have a swap method, it's totally fine to naming the parameters "a" and "b", the names "firstNumber" and "secondNumber" would add no meaning.
I'm on an assignment where I pointed out that several files I was in didn't even need to exist if we just used a consistent naming convention to our environments. Huge chunks of code could be removed and streamlined and hundreds of lines of business logic for special cases removed by taking a more consistent approach. Then, for the first time in my life, I heard the term "DRY" being used almost derogatorily. The only time I ever got to hear a positive programming principle, and it's used by the lead in a negative connotation. "Code doesn't need to be too smart. You don't have to be too DRY". I thank god almighty I only have a few days left at this place. :D
naming : this isn't the 1970's, where single letter variables were a language limitation. Variables like j, x, etc, should only be used for short loop control. I remember well the days when "b10" and such were your variable names, descriptive names are sooooo much better. IMSAI, Polymorphics, Pr1me, Atari... those are from when I started programming. Don't handicap yourself by using 40 year old naming conventions.
A habit I've recently picked up from the OneLoneCoder javidx -- starting your variable name with an indication of that variable's type: fElapsedTime == a float containing the elapsed time. I've found it particularly useful with some of the more exotic windows / opengl types like WNDCLASS and HGLRC (handle for a gl rendering context). I start into the arg list for a function, the IDE suggests to me what types it expects, and oh look! I need and HGLRC and I have a variable hglrcMain.
So the thing about naming: I like to use descriptive variable names when I'm dealing with identifiers that are globally visible, but if it's an identifier that's only visible within a small function, I tend to use shorter, less descriptive names. In general, the lengths of my variable names tend to be proportionate to the size of their scope.
@@lennysmileyface I still make sure that they're descriptive enough to be obvious. It's just that when I'm dealing with the global namespace I have to be more mindful about potential name collisions.
Use some code scanning tools to help. Some tools even have advanced cut and paste detection that spot the issues that cutting and pasting can cause. Glad to see you are at least wanting to bake security into your code. Keep it up.
I'm not a beginner, but I've been dealing with someone else's 3rd and 4th antipatterns in a lot of code lately and spending a lot of time on fixing them up.
I've been known to make too many code changes at once, and...have to backdate whole versions, testing source file after source file, after source file just to pinpoint what I broke.
I hate commented out code. Either it doesn't belong so get rid of it or it belongs and shouldnt be commented out. I was looking at a string array that held some keys for a data transaction, and 3 or 4 of them were commented out.
Just my 5 cents ;-) #1 This was quite hard for me to start using properly. Took me many months to get used to long, descriptive names. Why? Because in languages in which I've started learning to program variable names were only allowed to have one letter (Basic), two (FORTH) or in samples I've seen most of the names of procedures / functions / variables were mostly unreadable acronyms (I'm talking to you, C). #3 Holding horses to create a new branch / commit before diving into coding requires a LOT of practice with good mentor. #5 Some kind of root of the problem might be SRP done bad - seen this a lot of the time - have exception with call stack 2 pages long of 2-3 line functions with multiple arguments passed around. I really doubt that such code is easier to track / read than less than hundred lines function with flow clearly visible to the reader. And I do not mean to not segregate responsibility, but to avoid dangerous "metrics" like "no more than 5 lines of code", "no more than 3 function in a class" that are more harmful IMHO. Just keep an eye on cyclomatic complexity and you will be good ;-)
Is there a mentor in the Tampa, Fl area? I’m learning Flutter/Dart. I’m strongly motivated. I need to get out of construction. I am starting a family and need to be a better father and husband example. Working hard isn’t a problem.
As a self taught programmer of a couple years, I have two modes. I just try to get some part of my code working, focusing only on what it's doing. then once I either have it working or my brain is just too fried to continue, I spend a few commits doing formatting, adding comments, renaming things and otherwise refactoring. I have no idea whether this is good or not but I've never had another person to work with to comment on it.
It could become an issue if you work on a project with multiple developers. Maybe set up a local repo and only commit to the group repo after the cleanup phases?
1. Keep you code readable. Tweak usage of tabs, spaces and newlines to emphasize the structure of your code. 2. If your function takes or returns many variables, pass them in an associative array or object. (This one may seem weird, but it saves tons of time when you need to add new features to functions while keeping them backward compatible with the rest of the code.)
Similar thing could be to pass a struct containing an array pointer and it's length of using a c-like language that doesn't store the length as part of the array.
Just a thought. I already had a feature to add which sends emails. I kept it simple enough by following KISS since nothing else was specified. Then, I was asked to send emails for another reason. The logic was almost the same, so I thought I could refactor the code to reuse smartly the code, but I thought, by doing that, I would have to retest the already deployed feature since there were no automatic tests. I think I recopied the function back then, though I would probably have made the argument to remake it if many more variants were to come.
Simple is good, minimal is bad. I hate having to try to decode a single line that does about 400 hundred different things because the previous guy knew he could rather he shoulkd
@@GB_Rusty yep exactly, the more simpler, structurally atomic and encapsulated modular code you make, the more money you will save in long run in maintaining / migration or rewriting - that's my experience in embedded applications. Basically, write a code as if complete idiots will need to understand it after you. Writing a "smarty" code where one lines incorporates 100 instructions instead of 5 is bad, time consuming and confusing for everyone. Either way simple elegant "big" code with low cyclomatic complexity or "smarty" "small" code implementing the same solution usually compiles and assembles into similar assembly constructions - so you will improve nothing usually with short "smarty" code, only no one will be able to understand it after you.
It's often easier to write code than to read code. Because of that if you've written something using all your knowledge and ability, you'll not be able to read it any more.
For me, variable names like $x, or $a, etc are temporary variables. For example, I might store database results there before I process it and then discard $a.
My noobie antipatterns are: 1. Be consistent with how you name as well as case, etc. As a beginner, I think it is good to look up an already created standard and use it. For one, it takes away the stress of thinking everything up yourself. And second, when someone takes over your code, you can tell them, I used pep8, google style guide, or? They now know what the standard is, and instead of having to tell them, they can review it themself. 2. Not sure what it is called, but having long complex nested if statements. Unfortunately, I am going to condemn myself by stating this, but I think creating test cases are what is needed for lava flow, not version control...time to start writing some tests... I am unsure exactly why version control is going to prevent/help lava flow. If you are afraid to touch your code because you might break it, branching isn't going to prevent this. And it isn't going to correct it, either. It might give you a little peace of mind knowing that if you completely break it, you can always revert to a previous version. As far as correcting existing lava flow. Unfortunately, I think that just takes time. There is no easy way around it. Partly because you may have to talk to people and get their feedback on why things were done a certain way. Or talking to the business to get their requirements again.
1. This is just so true... I always have to take care that I use the same syntax for XPos and YPos and don't just have int Xpos; int YPos; That gets annoying as hell when you try to remember how you wrote it. When I have such stuff I normally shortly think about how I name it and then name it accordingly. 2. Ah yes... the giant ass if statement... I come across it quite often
I just want to point out that Git is just one version manager out of many. There are a lot of more user friendly ones than Git, but I am not sure if there are any free ones. I do love Git and use it both professionally and personally, but it is a steep learning curve without s good GUI. There are a lot of different version managers out there.
I try to avoid any project with any sizable bits of copy/pasted code. I especially hate it when someone copy/pastes my code around the repository; I think they are lazy and incompentent.
the 'lava flow' issue as you've explained also occurs as a result of how many large companies are run. You have to put down something working before deadline X, so some mistakes are made while getting it over the line on time. You do this, than another deadline comes along for another project. The issue repeats itself. Meanwhile you never get any time allocated to go back in and fix your slightly too tightly coupled "brittle as cast iron" code sat there like a block of solid lava. As tech debt usually is something seen by marketing and commercial branches as a waste not delivering anything to market with a visible return on investment. Meanwhile 5 years down the line all the issues have accumulated exponentially over time as different people come and go and the company is faced with a massive rebuild/migration effort just to keep the lights on and wonder why the bill is so high and if it's really necessary. This 'anti-pattern' doesn't only seem to catch the juniors out for said reasons.
I work in aerospace and space. You could also mention: writing "efficient" code for programmers with experience that is hard for non-programmers to debug, as in testers . Because at some point you always end up looking at the code. Hence it is inefficient when applied to overall cost of the project even though programmers are patting themselves on the back at how good their code is. What appears to be unnecessary verbosity at software unit levels can save time and money at systems levels. Basically the Travelling Salesman solution - if you make all the parts efficient the whole is lacking.
One anti pattern very common among beginners is: Adding or keeping unused code. I used to be like that. I'd add helper functions before I needed them. I didn't want to "waste" working code by throwing away "perfectly good code" even when it was no longer necessary. If a feature was removed I'd stil keep the class around 'in case I needed it later'. As I grew more experienced I realised that it's great to have as little code as possible, unused code is just a nuisance that should be removed. And with versioning you can always recover your old code anyways if you end up needing it again.
So #4 Cut and Paste is interesting. Everything you say is absolutely correct, I couldn't agree more. I am a lifelong PLC software developer however and there is a caveat here. In my world the end user of the software also maintains and even upgrades/modifies as needed. It is commonplace that the end user also has a very basic to nonexistent understanding of PLC code in whatever form it is written (ladder,structured text, function block, etc.). This is typical because the people assigned this job at the company (end user) are maintenance (electrical, hydraulic, mechanical, etc) and not programmers, just they have "some" programming knowledge. Because of this lack of knowledge it is common for us in the industry to intentionally write code in long form (copy and paste). I have seen many times that a perfectly great software engineer not get repeat work with a customer because of complaints that the code is "terrible". When in fact all that really means is that the end user does not know how to deal with neatly wrapped up functions that can be called on many times and instead needs to see everything written in the longest, most painful form possible. I have had projects containing many thousands of rungs of logic (or lines of structured text if you prefer) that could have honestly been wrapped up into a few hundred rungs while still being very easy to understand and follow. It is unfortunate that this is the case because it becomes of choice of: Do you want to do what you know to be programmaticaly correct? or do you want happy customers, thus food on the table? It is not much of a choice.
You are trying to describe an unknown "polthergeist" thing with just another unknown "abstraction" thing. Is it wise to suggest mitigating something that is hard to understand with another unknown and hard to grasp concept, such as abstraction?
Tips: one of the best programming concept or style is to write your constant variable in CAPITAL_LETTER, and the words should be separated by underscore (_) example: DATABASE_CONNECTION. Thanks Andy
I often have reverse cut and paste. I always try to not repeat code and always end up in a situation where I need a function to do the same thing as another funcion but sliiightly differently. But still different enough that I can't just add a variable or two and use the same function in both places. Also multifunctional functions are much more difficult to name.
As an example of a poltergeist pattern I once was working on a project and the main developer wrote his own string class. It had countless functions inside. When I ask him why he did it he said that his implementation was faster. He literally reinvented the wheel and in the end his implementation was not faster. he himself rarely used any of those functions. In turn the functions that I used were buggy. The whole idea added complexity and the benefit was just not there, quite the contrary. Needless to say he did not last very long in this position.
It can be very frustrating when you are reading some code that doesn't make sense. I've been guilty of it in the past so I can't be too mad about it haha
Could you describe more clearly the poltergeist pattern please? I did feel the way I create the folder structures and classes are trapped into this situation. Just like no one teach you how to describe the structures, they usually just teach about 'how to code'. I really hope there's anything I could find out, not just follow those pattern like GoF repeatly without any 100% understanding.
Which department not really important . Only thing important is you've to be passionate on your work . Nowadays self taught developers as are ruling the world . So be it , learn throughout the life
I don't think I do any of these, maybe the fifth one, Poltergeist, some times. It even happens that I don't like the existing syntax of an existing function (from some external library) so I write a new one that calls the one that I don't like. I guess that's a really bad thing…
I like your term "lava code" :) nice mental image of what's happening. I think the best thing is to try to complete projects as often as possible so you experience how bad these things are as quickly as possible.
Cut and paste inheritance. Seen this quite a bit in real life. Someone needs to do something, finds something in the codebase that does something similar - cut, paste, modify - and done. Makes for a lot of fun when it turns out there is a subtle bug in the initial code that is now pasted all over the place.
thanks men. i love people looking the big picture and giving such advice. i have kid. what is your advice for kds age arround 6 to12. learning programming
Actually, ambiguous naming is not always an issue (seriously!). In Haskell having a function declaration like f (x:xs) = x * x that's totally fine and more readable than a longer name. This entire list only really applies to imperative programming, but because beginners usually learn imperative languages (for some reason) this is not really an issue for this video
Data Encapsulation and Expression Oriented Programming can be used without adopting the whole of Object-Oriented Programming (i.e. learning multiple inheritance which leads to fragile base class syndrome) and Functional Programming (i.e. whose definition of types, monads and arrows is again needless overkill). Avoid global variables. Put the code that knows how to access specialised data structures in its own capsule so that the rest of your program never knows how that data is structured and uses it as a service, enabling you to change how that data is structured along with just those access methods without having to change a single line of code outside of that module. Functional Programming seems frightening too, but all you really need to take from it is the prohibition of a code module/function/subroutine having widespread side effects. Provided your code is like a tree and the fruit is allowed to take care of being sweet without the branches needing to know how they taste nice, or the apple has a side effect on the growth of the tree, you will be alright. What's great is that there is no equivalent to gravity in this analogy making it dangerous for a tree to grow a giant peach. So, a big database is just another object either in memory or accessed remotely and the rest of the software shouldn't care about the details of how this database is implemented, how it is cached, replicated, backed up, etc. Also, breaking the knowledge up into these modules that only know about the public interfaces of other modules means you can collaborate on the development of a complex system provided you don't remove legacy features established in an interface that may still be used by someone else working on the project. A code analysis tool can remove dead code that is never run by "main" when you come to optimise the build, so don't think you are doing the computer favours by removing stuff you guess is obsolete. This is about as bad as deleting every occurence of a constant that you feel is no longer needed but haven't proven is never relied upon.
About Version Control: Do you recommend to squash the commits when merging? Sometimes my commits are kind of chaotic, especially if I'm trying to fix a bug, they sometimes look like this: "Tried to fix X, but still not fully working" "Fixed X" "Fixed Y which got broken because of last commit" I wonder if it is actually important to know the individual steps afterwards how a bug was fixed, or one commit "Fixed X" would be enough. I think "Work in Progress" commits like these kind of add clutter to the history and make it confusing to follow along.
A commit message should say something about the code change, not "Tried fix X, but still not fully working". That doesn't say anything about the code change you have made. I use the conventions described in this blogpost for my commit messages: chris.beams.io/posts/git-commit/
I think that is an agreed upon convention that everyone understands and can mentally process so it shouldn't be a problem if your code is short/simple enough that you can't forget what i, j and k are while reading it.
@@javabeanz8549 yes, just don't fall into the trap of continuinng the letter sequence... A single lowercase l as a variable name should be a punishable sin, along with using uppercase I and O.
leaving dead code just because i scare is the worst to deal with as a beginner programmer :D i believe will be better with more practice. amazing video thanks
Sometimes beginners will take commandments like "don't duplicate" / "don't copy paste" too far and create new anti-patterns. I've seen beginners who - as soon as they see a few lines of code repeated in 2 places will try to refactor that into a helper-function. But sometimes that helper-function will end up having a complicated set of parameters to cover both use cases - which makes it significantly harder to understand what's going on. I'm usually pragmatic and argue that you should only refactor lines of code if they being duplicated more than 2 times, or are exactly the same.
The part about naming being hard reminds me: Programming is writing. There's a german saying about writing: Einer muss sich quälen, der Autor oder der Leser. Translation: One of these two has to do the hard work the writer or the reader.
That's somewhat similar to something I like to say when devs debate which programming language is the most important. Invariably, my answer is: English
A book that I found unvaluable for good programming techniques is Code Complete 2nd Ed.by Steve McConnell. It indeed mentions all bad practices mentioned on this video and of course how to avoid them. The advantage of this book is that is programming language agnostic.
NAMING CONVENTIONS Use descriptive names (adjective_verbs for variables, verbNoun for functions) dash-for-html-assets-and-css-selectors under_score_for_variable_names camelCaseForFunctionNames
Lots of small companies use anti patterns in their code all the time. I don't know exactly why that is but I'm beginning to believe that good coding practices conflict somewhat with economical targets because of time constraints. Mind you, these are NOT unsuccessful businesses. I suspect this will become a problem once these businesses want to grow further. Just thought I'd mention this interesting observation.
first minutes this guy speaks so much i thought like this but when i understand the subjects it is very useful and good shot.please give some more example.
What "noobie" antipatterns would you add to the list?
Submitting code that breaks the project. Quite popular among junior and even competitive developers especially who work under pressure.
Inadequate unit testing before submitting a big chunk.
I don't know if that's a noobie one (probably is because I am one) but think/talk about web based apps and their modularity (without frameworks). Another thing is writing code in non-optimal ways like using standard loops instead of some built-in methods created for that certain purpose. In regards of web development I'd like to hear about browser support. I know all this stuff boils down to "spaghetti" but still I think it's worth a mention. Perhaps something like testing your code before pushing into production?
Hey Andy, you have sparked me to pickup programming again, I want to learn Python, I took a class on JavaScript 8 years ago, I want to self teach myself programming, what you recommend I should do first?
Endless loops! As far as I remember from my recent workplace as automation developer, in order to wait for the application to respond, I wrote some endless loops... Didn't think of them as endless loops when writing, because assumed that somewhen the tests will continue (when they met the condition in the loop), but when coming in the morning to see the result/s of the Sanity tests, I realized that there was a system timeout and I had to re-login and continue the test/s from where they were stuck (due to the endless loop/s)... Therefore I added some VBScript "Or" conditions that prevented the loop/s from being endless... :)
01. 1:55 *Ambiguous naming:* Of variables, functions: Name them uniquely and in a way they explain.Use the variable like 'commenting'.
02. 4:49 *Magic Stings/Numbers:* If a value is repeated make it into variable/const. Replace the value with a var/const for context.
03. 6:39 *Lava Flow:* Dont make chunks of code which will make crash entire program if changed, use Git for backup.
04. 9:59 *Cut & Paste:* Dont use same code all over the place. repeated code -> refactor into modules, functions, classes -> one change of code should change everything rather than have to change the same code across different files.
05. 11:48 *Poltergeist:* Make it compact & concise and with less shortcuts/paths/references
To fully understand these, watch this video
3: use version control &/or Git for program structure simplicity
If you don't know these things, you shouldn't even be allowed to have a programming job.
This should be pinned
I wish copy-paste wasn't that often necessary. You work with an API that requires you, for every piece, say every GUI element it displays, or every event it handles, to obtain the context, obtain the instance of the API engine, instantiate a connector object compliant with its interface, configure it, declaring every field you never need as its respective default value explicitly, then apply the one single value you want to put in it and call the method that feeds it to the API engine. Or worse, generate an entirely new class which inherits after the API object and provides a dozen stub methods that do nothing because you don't need them, and one getter and one setter as required by the function you need. Dozens of files differing by 2-3 lines each from each other, just to satisfy API prerequisites.
@@bjarnestronstrup9122 If only.
My coding philosophy (which explicitly addresses the 5th point, poltergeists):
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery
0:00 Self-Hype.
0:52 What Is An Anti-Pattern?
1:46 #1) Ambiguous Naming.
4:43 #2) Magic Strings / Numbers.
6:35 #3) Lava Flow.
9:53 #4) Cut and Paste.
11:43 #5) Poltergeist.
14:17 More Self-Hype.
15:11 Outro.
Pretty much every RUclips toplist ever? :q
Hmm . Version control doesn't really help lava flow, you need to either 1. Always stay consistent with the existing styles and technology or 2. Complete the features in the new technology and refactor the existing code to match before pushing to production..
These are all good points, but they're code smells, or just bad design or programming. An antipattern is a specific thing: a *known solution to a problem* that leads to a bad design. (See the entries on C2 and Wikipedia for more detail.)
Thank you for saying what I wanted to say. These are not anti-patterns. Glad to see he is teaching people. sheesh
Totally agree. This are bad smells not anti-patterns. Even though the video is really informative for begginers he himself is confusing concepts.
He also redefined a lot of these phrases. "This means X but to me the problem is really Y." Then don't call it X.
@@daniel.watching He's self-taught. When I got my first job, my code impressed a seasoned algorithms engineer from a top school. The hiring manager thought I was a complete idiot, since I didn't know the names of various sort algorithms - even though I could show the fastest, or lowest memory way to sort any given data set, and then explain why neither of those are a good idea on a given real world project. After working with the post-doc guy, I learned a lot of the terminology. Which makes it easier to have non-technical conversations about technical topics, but hasn't really changed my code at all. It's like an engineer trying to talk to a doctor. If you know exactly how it works but don't say it in Latin, screw you. :p
I believe he's trying to say behavioural pattern rather than design pattern, but I would say your criticism is valid. It would have been much clearer to say something like bad programming habit rather than anti-pattern.
I’m 25 years into my development life, and these are seriously great anti patterns. Yes, read Uncle Bob - but what Andy has here is still a nice, concise set of things for beginners. I’ve seen senior developers violate these anti patterns! Great video I will share with a beginner friend!
Thanks Michael!! Cheers!
Great video. I'm self taught for the last 20 years, and I wasn't really sure what "Antipattern" really meant; thanks for the clarification. Number 4 is Don't Repeat Yourself (DRY) which is very well described in The Pragmatic Programmer.
The way you talk are really down to earth and helps me...as a self taught programmer to know that I'm not alone.
Thank you. Subscribed!
I've been a developer for over 4 decades. I'm telling you, this guy knows what he's talking about.
Naming things is hard. I often find myself thinking about names and googling synonyms for minutes.
One of the most challenging parts of programming for sure 😊
I expected the advice of keeping functions small.
There was a study that found that programming errors became noticeably more likely whenever a function was longer than could fit on a developer's screen.
When a function gets big enough to break that barrier, look for any kind of functionality that you could place into its own function.
Good variable names are more important the more long lived the variable. There is nothing wrong with using "I" or "N" for a loop index or a short variable name if the variable is only used in a few closely referenced lines of code.
Using “i” inside a for loop is pretty standard practice. That’s one of the few places where I think it’s appropriate to use.
@@AndySterkowitz n for a count, c for a character, p for a pointer-these are all fairly common and idiomatic, especially in string manipulation.
I have something to contribute. As the worst programmer ever, this one is very important to me. Which is, don't just type type type type up a lot of code. Test it EVERY step of the way as you write it. Test every little thing as you add to it. Because what I'll do otherwise, is find there are 100 different bugs in it at the end, and debugging it is like guessing the combination of a 100 combination lock.... in other words, even if you fix a bug, your program won't work and you maybe can't be sure that the thing you just fixed was something that should be changed because what you just did didn't fix all of what was wrong with your program and maybe it should have been the first way before and you just made it worse.
5:05 should be if (age >= 21) :P
I see you just used an antipattern. Have a look at the "Magic numbers" section of this video.
@@TheObliviJohn I think he sees that. His point is simple that the equal sign was missing because if you are exactly 21 you can drink in the USA
if (legalDrinkAge < age) is better in case of mix '=' with '==' ;o)
@@jankomuzykant1844 this is being very pedantic but I prefer the variable on the left since it reads like that is the one that changes and you are checking for.
Like in English we would say if you are over the drinking age. Not the drinking age is below you
@@keeyan2166 With some experience it's O.K.
TLDR=
Read "Clean Code" by Uncle Bob
Too long don't read...
But read an entire book??
And then realize it's for developers that have unlimited resources and no project manager pressure 😉
No, seriously. His books are great and understanding his opinions and common patterns he shows and why they make sense (to a certain extent, some things that uncle Bob mentions are definitely arguable) is important. Still, in the real world, you may not always be able to incorporate clean design decisions everywhere.
Also what's considered clean is arguable. If you throw in generics everywhere just to satisfy DRY (don't repeat yourself) and then obfuscate the code with the generics and make it hard to understand for beginners may not be the best decision if you have a team of junior developers.
I am a developer for over a decade now and I have seen very abstract code. The thing with code that abstracts everything nicely is that commonly only the people who designed it easily understand it.
@@jacqueskloster4085 This is a really good argument. I'm also very susceptible to writing these "beautiful" abstractions which can't even be named right 🙄
and/or Code Complete by Steve McConnell
lmao if you know the most common design patterns you will understand those „abstract code“ with ease.
Genius! I am a self taught programmer with now 35 years experience. This is EXACTLY correct. When you are coding it is all clear in your head. So you can follow all your shorthand naming etc. 6 months later your code will look like someone else wrote it. Dont follow these rules so others can read your code, do this for your own sake so you can understand it.
And do good layout of your code so its clear. Don't put multiple statements on the same line to save a carriage return. I have a party trick of identifying the location of bugs without reading the code. I scroll it super fast so it is a blur. When I see a "lump" of multi-line code, 90% chance that's where the bug is. I don't even have to know the programming language. Crappy layout = confusing code.
An exception to the long descriptive variable names is when you're writing scientific code and you're following a convention e.g. a position vector in physics is often just denoted by x. Also this helps with readability in complex expressions.
Similar thing with loop variables. It's a very common convention to name these with i, j, k, etc.
@@zombiedude347 Also counts are often denoted by m or n, e.g. number of items, dimensions or iterations.
I have been teaching myself C# via Unity almost daily for the past year. I have one strong recommendation. When starting out, and learning how your codes function, take the time to build small test programs. This will deepen your understanding of the code, and how to make it work well, instead of just work. I stumbled through Unity's low level networking API to get my software working, only to have what I did hinder my progress for over 4 months. I recently built a small test system to really understand what was happening during network connections, disconnections, messages, etc. and only then did I realize I had hobbled myself months earlier. Happy to say that my programs are running twice as well as they were before, simply because I took an hour or two to make a test program. If I had done so in the beginning, I would have saved myself dozens of hours of trial and error.
As someone who is largely self taught, has a computing degree.
Naming. This is a tricky one, the Code Complete book that others mentioned (an excellent book, that I recommend every developer should read, I still pick it up occasionally). Anyway, that book has a whole chapter (around 30 I believe), in naming things. The goal of code is that it is clear and concise. Sometimes just naming something x is enough, like if a function only uses/ returns one variable because the name of the function already (or should) tell what x is.
Another great/ essential book is Head first design patterns. Patterns are powerful tools that can be used to solve problems without having to reinvent the wheel. A mistake beginners make is that they try to use patterns everywhere even when a pattern is a poor fit. Things like DRY are adhered to like a religion when breaking code up further only makes it harder to understand. There's often many ways to do things, with some better than others and more complicated than simply right or wrong.
Last tip is to spend time learning data structures, it may not feel like much fun, but it will massively help you in the long run.
And it's a very good practice to have 'Programming Buddy', I mean to have someone to give them your programs to debug them, because sometimes we are too 'infatuated' with our creation that we can't see the shortcomings. Just like a mother who can't see their children wrongdoings. So to have coding buddy gives us the opportunity to see our code from another person perspective, which is extremely helpful to find bugs or improve our code.
Or go away from your code for.a while ... like a day or two or a week. When you return, review your code again; it will be like you are seeing it for almost the first time with fresh eyes. You will see issues that you didn't see previously.
@@BruceBigby good advice.
Very nice video, congratulations. I would like to comment on the book example at around 03:10, for ambiguous names. The problem with the metaphor is that a book written with extensive vocabulary that makes you consult a dictionary frequently is GOOD, not bad. You not only enjoy the book (hopefully), but you also learn. Reading words you didn't know is positive. Ambiguous naming would rather be like an author naming all his or her characters with random strings of 20 digits, so each time something happens to someone you would have a hard time guessing who it happened to, without constantly looking up a table, and probably even confusing a character for another one, because they differ only in the 17th digit.
CLIFFS: every programmer should watch Uncle Bob Martin Clean Code Foundations Episodes 1 2 and 3! Seriously, will solve most of these "rude code" anti-patterns. TDD and make it work then Extract Function like crazy FTW!
I worked in an old C# application in which someone thought it was a good idea to use reflection to jump to methods that handled every UI state in a Web Forms app. The naming was bad, like "lb_42", and the IDE was not of any help. It just showed that there was a lot of methods without any reference.
You never touch that code unless you have to rewrite the whole application!
Professional software development can be such dirty work when handling legacy code that has historically lacked code conventions.
Once took over a project where the vars were named like „cr_42_bp_csr_vt_3“. Supposedly abbreviations that were meant to tell the dev something.
About Magic String / Numbers: Would you then agree that Javascript is badly designed? Because it is full of magic strings and numbers. E.g. window.addEventListener("click", ...) or if (response.status === 200) ...
Judging by the code I've seen most developers write, naming functions is easy. Simply choose from this list. "Setup","Init" "Build" , "Load". What should the function do? Anything you want. Extra points for performing multiple unrelated tasks and extending your function across three or more pages.
Re: magic numbers: These can be the source of some nasty bugs, especially in embedded software. Hard coded numbers for memory allocation, for example, can remain dormant for a long time until that right circumstance comes up to break the software. Don't assume that the number is "appropriate" (like 21 for drinking age) or the "right size" (as with static memory allocation). Always code for flexibility and a dynamic environment.
OTOH, don't be anal about magic numbers that are really, really self-explainatory and not likely to change over the next century. if(minute>=60){minute = 0; hour ++;} - are you seriously going to #define MINUTES_IN_AN_HOUR ?
@@sharpfang yes, because if for any reason someone wants to change the frequency of execution or something or has any other random reason to change this number, because pattern switched from minutes in an hour to hours of a day and the smart junior developer goes all like "I got this, replace all is my friend" he overwrites the other thing were the 5 dozen egg crate capacity is hardcoded. Cost you nearly nothing, especially with good IDE, and makes life so much easier. Don't be the smart junior, don't be me 15 years ago
@@patrickebert5748 So, you think that changing the frequency of execution is best achieved by changing the number of minutes in an hour. And a code that has minutes_in_an_hour=80 is a better code, and someone trying to determine why a function launches 9 times a day when it should launch 12 times will have an easier time debugging this.... because seeing if(minute >= minutes_in_an_hour){ minute=0; hour++;} will obviously make it clear the hour changes after 80 minutes...
Important clarification here. Every single programmer in the world is self-taught. The only difference is whether you had someone else evaluating the quality of you knowledge over time or you didn't. If you're good at being honest about self evaluation then self learning outside of a formal setting is feasible, otherwise you self learn inside a setting where you are subject to 3rd party evaluations of your progress.
No one can learn for you.
This! I tend to really get triggered when people use this phrase.
That's not what self-taught means. Being self-taught means having no teacher.
@@MrCmon113 no it doesn't.
From the dictionary:
"cause (someone) to learn or understand something by example or experience."
The above statement is a huge lie. No person can cause another person to understand something. Only the individual learning is able to develop understanding. A teachers role is to evaluate the level of understanding that the student has achieved and to correct any mis-learning that may have occured.
The idea that a treacher can cause someone to understand something is one of the greatest lies ever told. There are more than a dozen people that I know personally who have failed to achieve what they could have in life because they believed the lie that it was the teachers role to imbue them with knowledge.
I agree with all the points here and urge people to take them seriously.
However, I would not call these kinds of quality problems "antipatterns", but for example "bad programming practices". I tend to use the word "antipattern" for common patterns of bad design, as in design patterns. I think the word was popularized by the Brown et. al. book in the late 90's.
The distinction between problems in design and problems in code quality is a meaningful one. For example if a variable is named 'a' and it in reality means 'username', it's a code quality issue. Refactoring to change the variable name after review is easy. But if the variable refers to an object with such widely varying responsibilities and convoluted structure, that a good name for it simply does not exist, the issue if more fundamental to the system.
One anti-pattern I often see is parallel arrays/lists where related data is stored across multiple collections instead of one type/class to hold the data and then one collection to hold each set of data.
I find myself occasionally still doing the first two. I have been trying to unlearn that habit, but it's not that easy to get rid of, especially when you just want some code down quickly before your mind starts to wander and you forget what you were doing (I have trouble staying focused for long)
Great video. I am also a self taught developer, been doing this for 40 years now. I am curious about your comment on testing in regards to lava flow. I have found that automated unit test specifically helps with this. When I am coding a new function, where an automated test is possible, I write the test first, then the function.
Another good telltale for needing a named constant is if a value is tied to a business concept that's fairly unchanging, like a company code or location ID. Thanks for sharing!
What I would like to add to ambiguous naming: Usually, the smaller the scope of the variable, the less specific the name has to be.
In a for loop, it is totally okay to call the counter "i" instead of "index". As well, if a method is called "getCustomerList", you do not need to call the variable you return "customerList", "result" would be specific enough because the function name already says what the result is. Or if you have a swap method, it's totally fine to naming the parameters "a" and "b", the names "firstNumber" and "secondNumber" would add no meaning.
*Top Tip:* Take coffee and stare at codes all the night. You will be a software developer
🤣🤣🤣
I think you mean take cocaine and stare at code all night dude lol.
Nah jks.
haha 🤣
@@frayedsanity Kidding not kidding. jk
I'm on an assignment where I pointed out that several files I was in didn't even need to exist if we just used a consistent naming convention to our environments. Huge chunks of code could be removed and streamlined and hundreds of lines of business logic for special cases removed by taking a more consistent approach.
Then, for the first time in my life, I heard the term "DRY" being used almost derogatorily. The only time I ever got to hear a positive programming principle, and it's used by the lead in a negative connotation. "Code doesn't need to be too smart. You don't have to be too DRY".
I thank god almighty I only have a few days left at this place. :D
naming : this isn't the 1970's, where single letter variables were a language limitation. Variables like j, x, etc, should only be used for short loop control. I remember well the days when "b10" and such were your variable names, descriptive names are sooooo much better. IMSAI, Polymorphics, Pr1me, Atari... those are from when I started programming. Don't handicap yourself by using 40 year old naming conventions.
A habit I've recently picked up from the OneLoneCoder javidx -- starting your variable name with an indication of that variable's type:
fElapsedTime == a float containing the elapsed time.
I've found it particularly useful with some of the more exotic windows / opengl types like WNDCLASS and HGLRC (handle for a gl rendering context). I start into the arg list for a function, the IDE suggests to me what types it expects, and oh look! I need and HGLRC and I have a variable hglrcMain.
So the thing about naming: I like to use descriptive variable names when I'm dealing with identifiers that are globally visible, but if it's an identifier that's only visible within a small function, I tend to use shorter, less descriptive names.
In general, the lengths of my variable names tend to be proportionate to the size of their scope.
Why though? To save a little bit of time? You should write names as if someone else will read your code.
@@lennysmileyface I still make sure that they're descriptive enough to be obvious. It's just that when I'm dealing with the global namespace I have to be more mindful about potential name collisions.
Learning about good practices and *security* it's always hard for me, I'm moving really slow
Use some code scanning tools to help. Some tools even have advanced cut and paste detection that spot the issues that cutting and pasting can cause.
Glad to see you are at least wanting to bake security into your code. Keep it up.
I'm not a beginner, but I've been dealing with someone else's 3rd and 4th antipatterns in a lot of code lately and spending a lot of time on fixing them up.
I've been known to make too many code changes at once, and...have to backdate whole versions, testing source file after source file, after source file just to pinpoint what I broke.
I hate commented out code. Either it doesn't belong so get rid of it or it belongs and shouldnt be commented out. I was looking at a string array that held some keys for a data transaction, and 3 or 4 of them were commented out.
I agree, it's also what we have VCS for, don't use that code? Rip it out! Need it again? It's in VCS somewhere
Just my 5 cents ;-)
#1 This was quite hard for me to start using properly. Took me many months to get used to long, descriptive names. Why? Because in languages in which I've started learning to program variable names were only allowed to have one letter (Basic), two (FORTH) or in samples I've seen most of the names of procedures / functions / variables were mostly unreadable acronyms (I'm talking to you, C).
#3 Holding horses to create a new branch / commit before diving into coding requires a LOT of practice with good mentor.
#5 Some kind of root of the problem might be SRP done bad - seen this a lot of the time - have exception with call stack 2 pages long of 2-3 line functions with multiple arguments passed around. I really doubt that such code is easier to track / read than less than hundred lines function with flow clearly visible to the reader. And I do not mean to not segregate responsibility, but to avoid dangerous "metrics" like "no more than 5 lines of code", "no more than 3 function in a class" that are more harmful IMHO. Just keep an eye on cyclomatic complexity and you will be good ;-)
Or "no more than X levels of indentation", with the result being dozens of tiny, generic/ambiguous functions that only ever get called from one place.
Is there a mentor in the Tampa, Fl area? I’m learning Flutter/Dart. I’m strongly motivated. I need to get out of construction. I am starting a family and need to be a better father and husband example. Working hard isn’t a problem.
Okay, sounds like programmers would LOVE "Table of Content" and "Index" like page from books.
As a self taught programmer of a couple years, I have two modes. I just try to get some part of my code working, focusing only on what it's doing. then once I either have it working or my brain is just too fried to continue, I spend a few commits doing formatting, adding comments, renaming things and otherwise refactoring. I have no idea whether this is good or not but I've never had another person to work with to comment on it.
It could become an issue if you work on a project with multiple developers. Maybe set up a local repo and only commit to the group repo after the cleanup phases?
Is that a uni qlo hoodie? I just bought the t-shirt version for my son in blue.
1. Keep you code readable. Tweak usage of tabs, spaces and newlines to emphasize the structure of your code. 2. If your function takes or returns many variables, pass them in an associative array or object. (This one may seem weird, but it saves tons of time when you need to add new features to functions while keeping them backward compatible with the rest of the code.)
Similar thing could be to pass a struct containing an array pointer and it's length of using a c-like language that doesn't store the length as part of the array.
Just a thought. I already had a feature to add which sends emails. I kept it simple enough by following KISS since nothing else was specified. Then, I was asked to send emails for another reason. The logic was almost the same, so I thought I could refactor the code to reuse smartly the code, but I thought, by doing that, I would have to retest the already deployed feature since there were no automatic tests. I think I recopied the function back then, though I would probably have made the argument to remake it if many more variants were to come.
Im still learing, but yeah, having too much code is often mistaken as being a pro. But you should try to keep it simple, especially when your fresh.
Simple is good, minimal is bad. I hate having to try to decode a single line that does about 400 hundred different things because the previous guy knew he could rather he shoulkd
@@GB_Rusty yep exactly, the more simpler, structurally atomic and encapsulated modular code you make, the more money you will save in long run in maintaining / migration or rewriting - that's my experience in embedded applications. Basically, write a code as if complete idiots will need to understand it after you. Writing a "smarty" code where one lines incorporates 100 instructions instead of 5 is bad, time consuming and confusing for everyone. Either way simple elegant "big" code with low cyclomatic complexity or "smarty" "small" code implementing the same solution usually compiles and assembles into similar assembly constructions - so you will improve nothing usually with short "smarty" code, only no one will be able to understand it after you.
It's often easier to write code than to read code. Because of that if you've written something using all your knowledge and ability, you'll not be able to read it any more.
For me, variable names like $x, or $a, etc are temporary variables. For example, I might store database results there before I process it and then discard $a.
My noobie antipatterns are:
1. Be consistent with how you name as well as case, etc. As a beginner, I think it is good to look up an already created standard and use it. For one, it takes away the stress of thinking everything up yourself. And second, when someone takes over your code, you can tell them, I used pep8, google style guide, or? They now know what the standard is, and instead of having to tell them, they can review it themself.
2. Not sure what it is called, but having long complex nested if statements.
Unfortunately, I am going to condemn myself by stating this, but I think creating test cases are what is needed for lava flow, not version control...time to start writing some tests...
I am unsure exactly why version control is going to prevent/help lava flow. If you are afraid to touch your code because you might break it, branching isn't going to prevent this. And it isn't going to correct it, either. It might give you a little peace of mind knowing that if you completely break it, you can always revert to a previous version.
As far as correcting existing lava flow. Unfortunately, I think that just takes time. There is no easy way around it. Partly because you may have to talk to people and get their feedback on why things were done a certain way. Or talking to the business to get their requirements again.
1. This is just so true... I always have to take care that I use the same syntax for XPos and YPos and don't just have
int Xpos;
int YPos;
That gets annoying as hell when you try to remember how you wrote it.
When I have such stuff I normally shortly think about how I name it and then name it accordingly.
2. Ah yes... the giant ass if statement... I come across it quite often
@@mauricestardddude8317 did I make it plural or singular? And use switch/case where appropriate...
I think over reliance on classes is an anti pattern. Do not extend a class just to reuse code. Composition > Inheritance
If there is one single advice I would give new devs is to understand and master what SOLID means. Nice channel with good content Andy!
I just want to point out that Git is just one version manager out of many. There are a lot of more user friendly ones than Git, but I am not sure if there are any free ones.
I do love Git and use it both professionally and personally, but it is a steep learning curve without s good GUI. There are a lot of different version managers out there.
5:08 That doesn't include "21", though - only 22 and above. Oops.
I try to avoid any project with any sizable bits of copy/pasted code. I especially hate it when someone copy/pastes my code around the repository; I think they are lazy and incompentent.
That doubleirish dutchsandwich sounds delicious. I am thinking egg salad with some Irish twist.
the 'lava flow' issue as you've explained also occurs as a result of how many large companies are run. You have to put down something working before deadline X, so some mistakes are made while getting it over the line on time. You do this, than another deadline comes along for another project. The issue repeats itself. Meanwhile you never get any time allocated to go back in and fix your slightly too tightly coupled "brittle as cast iron" code sat there like a block of solid lava. As tech debt usually is something seen by marketing and commercial branches as a waste not delivering anything to market with a visible return on investment. Meanwhile 5 years down the line all the issues have accumulated exponentially over time as different people come and go and the company is faced with a massive rebuild/migration effort just to keep the lights on and wonder why the bill is so high and if it's really necessary. This 'anti-pattern' doesn't only seem to catch the juniors out for said reasons.
About the naming, we get that from textbooks/teaching sites that give us examples and name a function myFunc().........
I work in aerospace and space. You could also mention: writing "efficient" code for programmers with experience that is hard for non-programmers to debug, as in testers . Because at some point you always end up looking at the code.
Hence it is inefficient when applied to overall cost of the project even though programmers are patting themselves on the back at how good their code is.
What appears to be unnecessary verbosity at software unit levels can save time and money at systems levels. Basically the Travelling Salesman solution - if you make all the parts efficient the whole is lacking.
One anti pattern very common among beginners is: Adding or keeping unused code. I used to be like that. I'd add helper functions before I needed them. I didn't want to "waste" working code by throwing away "perfectly good code" even when it was no longer necessary. If a feature was removed I'd stil keep the class around 'in case I needed it later'.
As I grew more experienced I realised that it's great to have as little code as possible, unused code is just a nuisance that should be removed. And with versioning you can always recover your old code anyways if you end up needing it again.
So #4 Cut and Paste is interesting. Everything you say is absolutely correct, I couldn't agree more. I am a lifelong PLC software developer however and there is a caveat here. In my world the end user of the software also maintains and even upgrades/modifies as needed. It is commonplace that the end user also has a very basic to nonexistent understanding of PLC code in whatever form it is written (ladder,structured text, function block, etc.). This is typical because the people assigned this job at the company (end user) are maintenance (electrical, hydraulic, mechanical, etc) and not programmers, just they have "some" programming knowledge. Because of this lack of knowledge it is common for us in the industry to intentionally write code in long form (copy and paste). I have seen many times that a perfectly great software engineer not get repeat work with a customer because of complaints that the code is "terrible". When in fact all that really means is that the end user does not know how to deal with neatly wrapped up functions that can be called on many times and instead needs to see everything written in the longest, most painful form possible. I have had projects containing many thousands of rungs of logic (or lines of structured text if you prefer) that could have honestly been wrapped up into a few hundred rungs while still being very easy to understand and follow. It is unfortunate that this is the case because it becomes of choice of: Do you want to do what you know to be programmaticaly correct? or do you want happy customers, thus food on the table? It is not much of a choice.
You are trying to describe an unknown "polthergeist" thing with just another unknown "abstraction" thing. Is it wise to suggest mitigating something that is hard to understand with another unknown and hard to grasp concept, such as abstraction?
Tips: one of the best programming concept or style is to write your constant variable in CAPITAL_LETTER, and the words should be separated by underscore (_) example: DATABASE_CONNECTION. Thanks Andy
I often have reverse cut and paste. I always try to not repeat code and always end up in a situation where I need a function to do the same thing as another funcion but sliiightly differently. But still different enough that I can't just add a variable or two and use the same function in both places. Also multifunctional functions are much more difficult to name.
As an example of a poltergeist pattern I once was working on a project and the main developer wrote his own string class. It had countless functions inside. When I ask him why he did it he said that his implementation was faster. He literally reinvented the wheel and in the end his implementation was not faster. he himself rarely used any of those functions. In turn the functions that I used were buggy. The whole idea added complexity and the benefit was just not there, quite the contrary. Needless to say he did not last very long in this position.
That first point is teached from the beginning in the head first books, and it's great, i hate when i see names that don't explain what they do
It can be very frustrating when you are reading some code that doesn't make sense. I've been guilty of it in the past so I can't be too mad about it haha
#1 1:50 Ambiguous Naming of variables, functions. etc.
#2 4:46 Magic Strings / Numbers
#3 6:35 Lava Flow Pattern (spaghetti code)
#4 9:55 Repeating Code (copy-paste - ing code)
#5 11:45 Poltergeist anti-pattern
I have been a professional software developer for over a decade, and I was not self-taught. This is all good advice.
This was really insightful Andy! Good stuff.
Could you describe more clearly the poltergeist pattern please? I did feel the way I create the folder structures and classes are trapped into this situation. Just like no one teach you how to describe the structures, they usually just teach about 'how to code'.
I really hope there's anything I could find out, not just follow those pattern like GoF repeatly without any 100% understanding.
Is Bachelor of Computer Application's BCA is good course for learn cooding and as well as to enter in IT field ?
Which department not really important . Only thing important is you've to be passionate on your work . Nowadays self taught developers as are ruling the world . So be it , learn throughout the life
@@Ram-fd9er Thanks for your helpful reply
I don't think I do any of these, maybe the fifth one, Poltergeist, some times. It even happens that I don't like the existing syntax of an existing function (from some external library) so I write a new one that calls the one that I don't like. I guess that's a really bad thing…
What about C and C++ built in functions? They have shitty names too (for example atoi).
I like your term "lava code" :) nice mental image of what's happening. I think the best thing is to try to complete projects as often as possible so you experience how bad these things are as quickly as possible.
Cut and paste inheritance. Seen this quite a bit in real life. Someone needs to do something, finds something in the codebase that does something similar - cut, paste, modify - and done. Makes for a lot of fun when it turns out there is a subtle bug in the initial code that is now pasted all over the place.
It's a really nice feeling watching this a discovering I've stopped doing those a long time ago.
thanks men. i love people looking the big picture and giving such advice. i have kid. what is your advice for kds age arround 6 to12. learning programming
5:20 === compares not only variable values but also types of those variables in javascript. Just for anyone wondering :)
Am 18 yrs am trying to learn coding,
Please which programming language is the best to start with
Actually, ambiguous naming is not always an issue (seriously!). In Haskell having a function declaration like f (x:xs) = x * x
that's totally fine and more readable than a longer name. This entire list only really applies to imperative programming, but because beginners usually learn imperative languages (for some reason) this is not really an issue for this video
Here's a like and a comment for the RUclips algorithm because I love you and appreciate you, Andy.
Data Encapsulation and Expression Oriented Programming can be used without adopting the whole of Object-Oriented Programming (i.e. learning multiple inheritance which leads to fragile base class syndrome) and Functional Programming (i.e. whose definition of types, monads and arrows is again needless overkill). Avoid global variables. Put the code that knows how to access specialised data structures in its own capsule so that the rest of your program never knows how that data is structured and uses it as a service, enabling you to change how that data is structured along with just those access methods without having to change a single line of code outside of that module. Functional Programming seems frightening too, but all you really need to take from it is the prohibition of a code module/function/subroutine having widespread side effects. Provided your code is like a tree and the fruit is allowed to take care of being sweet without the branches needing to know how they taste nice, or the apple has a side effect on the growth of the tree, you will be alright.
What's great is that there is no equivalent to gravity in this analogy making it dangerous for a tree to grow a giant peach. So, a big database is just another object either in memory or accessed remotely and the rest of the software shouldn't care about the details of how this database is implemented, how it is cached, replicated, backed up, etc. Also, breaking the knowledge up into these modules that only know about the public interfaces of other modules means you can collaborate on the development of a complex system provided you don't remove legacy features established in an interface that may still be used by someone else working on the project. A code analysis tool can remove dead code that is never run by "main" when you come to optimise the build, so don't think you are doing the computer favours by removing stuff you guess is obsolete. This is about as bad as deleting every occurence of a constant that you feel is no longer needed but haven't proven is never relied upon.
if (girlsAge
😂😂😂
// who cares about age
tapThat();
while(age < legalAgeOfConsent){}
TapThat().
while (grimMonolith.hasPowerArtifact) {
tapThat();
untapThat();
}
assert(mana > n for all natural numbers n);
@@jonaskoelker Be glad mana burn is no longer a thing.
About Version Control: Do you recommend to squash the commits when merging? Sometimes my commits are kind of chaotic, especially if I'm trying to fix a bug, they sometimes look like this:
"Tried to fix X, but still not fully working"
"Fixed X"
"Fixed Y which got broken because of last commit"
I wonder if it is actually important to know the individual steps afterwards how a bug was fixed, or one commit "Fixed X" would be enough. I think "Work in Progress" commits like these kind of add clutter to the history and make it confusing to follow along.
A commit message should say something about the code change, not "Tried fix X, but still not fully working". That doesn't say anything about the code change you have made. I use the conventions described in this blogpost for my commit messages: chris.beams.io/posts/git-commit/
Regarding ambiguous naming, what about using i j and k for iterating in nested for loops?
I think that is an agreed upon convention that everyone understands and can mentally process so it shouldn't be a problem if your code is short/simple enough that you can't forget what i, j and k are while reading it.
@@Tassdo short and simple being the key!
@@javabeanz8549 yes, just don't fall into the trap of continuinng the letter sequence... A single lowercase l as a variable name should be a punishable sin, along with using uppercase I and O.
That first one about variable naming seems to be the standard in Go.
Allen Hundley this is also what I thought when watching the video
*Beginner - intermediate programmer*
Uint32 runtime = SDL_GetTicks(); // gets no. of milliseconds once program starts
*advanced programmer*
int elapsed = SDL_GetTicks();
11:01 numberButton(e) what is e? What happened with the first rule of this video?
leaving dead code just because i scare is the worst to deal with as a beginner programmer :D i believe will be better with more practice. amazing video thanks
One thing I'd like to add to your first point (Might apply to yourself:). If naming your method/function is hard, it is probably trying to do to much.
Sometimes beginners will take commandments like "don't duplicate" / "don't copy paste" too far and create new anti-patterns. I've seen beginners who - as soon as they see a few lines of code repeated in 2 places will try to refactor that into a helper-function. But sometimes that helper-function will end up having a complicated set of parameters to cover both use cases - which makes it significantly harder to understand what's going on.
I'm usually pragmatic and argue that you should only refactor lines of code if they being duplicated more than 2 times, or are exactly the same.
Your room needs some acoustic treatment. Hanging some thick blankets will help with the echo/reflections.
The part about naming being hard reminds me: Programming is writing.
There's a german saying about writing: Einer muss sich quälen, der Autor oder der Leser.
Translation: One of these two has to do the hard work the writer or the reader.
That's somewhat similar to something I like to say when devs debate which programming language is the most important. Invariably, my answer is: English
Is that a MSI GTX 1070 Ti ARMOR on the shelf in the background ? ;)
A book that I found unvaluable for good programming techniques is Code Complete 2nd Ed.by Steve McConnell.
It indeed mentions all bad practices mentioned on this video and of course how to avoid them.
The advantage of this book is that is programming language agnostic.
NAMING CONVENTIONS
Use descriptive names (adjective_verbs for variables, verbNoun for functions)
dash-for-html-assets-and-css-selectors
under_score_for_variable_names
camelCaseForFunctionNames
At 5:50 you seem to have a off-by-one error :) yet another anti-pattern
or off by a very small fraction, JS isnt type safe, age could be a floating point number.
05:47 or better: You could have those configuration constants in an extra class, so that you can mock this configuration for unit testing.
Lots of small companies use anti patterns in their code all the time. I don't know exactly why that is but I'm beginning to believe that good coding practices conflict somewhat with economical targets because of time constraints. Mind you, these are NOT unsuccessful businesses. I suspect this will become a problem once these businesses want to grow further. Just thought I'd mention this interesting observation.
first minutes this guy speaks so much i thought like this but when i understand the subjects it is very useful and good shot.please give some more example.