"An idiot admires complexity, a genius admires simplicity, a physicist tries to make it simple. An idiot will make everything so complicated you'll think he's a god for understanding it." -paraphrased, Terry A. Davis As deranged as he was, these are words to live by, both for designing software and life in general.
*5 Ways to Improve Your Code* 1. Minimize the need for Comments, Code should explain what it does. Write a comment to explain [why you make that choice] rather explaining [what it does]. 2. Avoid Long Methods (Avoid creating long methods it's hard to read, maintain & troubleshoot), prefer short methods over long methods 3. Avoid Long Parameter List (use max 2 parameters) 4. Avoid Duplicated Code (Duplicated code is maintenance overhead) 5. Avoid Complex Conditional code (Avoid large block of code in single condition)
The biggest problem is that programmers code before structuring and/or understanding the data. On many contracts I am asked why I am not coding. I say I am organizing the data. That does not go over well. I get heat from management. I persist and normally finish with a very stable solution before the allotted time. I have worked on pacemakers, motor control, heat, HVAC, aviation, proprietary RTOSs, search systems and more. I am a very big fan of structuring my data like organized MUD.
There does not exist any rigorous definition of what "clean code" means. It's largely informed by gut feeling, and any attempt to capture the meaning via rules of thumb fails half the time anyway.
@@ubercorey No problem. :-) This field is extremely opinionated, so always asking why and putting serious thought into peoples answers will cut through most of the bullshit. For example, the fact that Continuous Delivery uses science and statistics to inform his opinions, means he should be listened to. Also, be very suspicious of any dogma. Personally I try to avoid using nebulous words like clean. I try to find more precise words to convey what I actually mean by clean. For example "this code is easy to read/understand" or "this code is easy to edit" or "this code follows my organisations best practices" rather than "this code is clean".
@@ContinuousDelivery I agree, but wow are there office politics to be considered, too. I had untold trouble even when I could (actually ESPECIALLY when I could) prove that I improved code. Some co-workers don't like that, and coding is often a social endeavour.
@@ericpmoss exactly. when the product owner moto is : if it ain't broke don't fix it, you are not allowed to touch any line of code that are not directly impacting your functional changes.
I also like that one: "Make the change simple, then make the change". So refactor before making a change. But don't forget to do it in separate commits!
Comment every line! And I mean every line. I learned this the tough way from a colleague in my first software engineering job. I hated his code for it; I kept repeating to him, like you, that code should be self commenting, etc, and coming out with all the arguments against comments that we all know very well. But after 3yrs working with him (back then) I couldn't deny an unavoidable truth - his code never, and I mean never, not once, had a bug in it! How could I tell this programmer what to do, when I couldn't say the same for my code. That was tough for me to admit. But I opened my eyes, and had a go at copying his style, commenting every line ... like you say, it's important to comment sincerely, not just flippantly saying what the syntax is doing ... and to my amazement, overnight, I went from producing typically buggy code like most programmers, to producing completely bug free code just like the guy I was now copying. So what gives? What is making the difference? It's quite simple, and became abundantly apparent once I tried it. Pedantically commenting *every* line (when done sincerely, and *not* simply describing the syntax, etc), makes sure that you know what you are doing, and acts as a comprehensive self-review. It sounds like "well, durh!!" but I subsequently found it amazing how often I'd write a line of code, go to write the comment above it, then realise "ah, hang on, that's not quite what I intended to do", or realise a subtle short coming with the algorithm I was writing, etc. Often even going back to completely re-write the function when I suddenly realised the whole function wasn't doing quite what I intended, or that it might be subject to problematic edge cases that I hadn't thought of when I set out writing the function, but that had then sprung to mind when writing the comments. Even simple lines like incrementing a counter (index++). Once you come to write a meaningful comment for that increment, for example "move to the next element in the zzz list" (or whatever the context)... that prompts you to think... "ah... but what if we're now past the end of the array? have I put the check in?". And so on. All of this being identified and realised before the code has ever been run, not even from the development environment. And commenting every line, forces you to make sure each line has a clear, simple role. If you have a complex line that's doing a lot, then commenting every line forces you to break it up. And that often also reveals problems with that code that you'd written. It's funny how typically the most difficult lines to comment in this manner, are the ones where you're not really sure what you're doing. Pedantically commenting every line means there's no hiding! You can't get away with just writing a line of code in the 'hope' that it's probably correct. If you can't write a meaningful comment above a line, if you're being honest with yourself, it's usually because you don't *really* know what you're doing, and realistically you need to re-think it until you do know what you're doing. A professional programmer should not need to step through a section of code they are writing on the debugger in order to evaluate what it's doing!! A professional programmer should confidently know what each and every line of code will do when they write it!! For that professional programmer, commenting every line of code, at the time of writing, is easy. In fact, that's probably a good guide for programmers to self-evaluate how far they have come as a professional. If you are able to comment every line of code, meaningfully, as you write it, that's probably a sign of a good, experienced professional. The programmers you should be concerned about are the ones who can't - and therefore obviously won't - buy into this approach. I've subsequently had lots of arguments with colleagues who think I'm just a thick, dumb idiot for doing it. The majority throwing the same arguments back at me, that I used to throw at that original colleague all those years ago. Some try to setup code style rules to prohibit it. But I always have one challenge for them. I say I'll listen to you, if you produce code as bug free as I, and that original colleague, do. In the 20 yrs since I learned this technique from that original colleague in my first job, no subsequent colleague has yet met that challenge - though a number have listened and observed, and tried this approach and become converts. Ironically, some of those I've argued this with over the years have also argued quite vociferously that (and I quote one them) "Software is always buggy!". They don't believe you can write bug free code. They refuse to believe you. And refuse to even give it a shot. They believe they are right - that software is always buggy - and, in practice their own code invariably reinforces their claims!
oh god. I couldn't even finish this comment, it's almost as if you commented every line in your comment. If you need to write comments to evaluate what you've coded, where the hell are your unit tests?
@@ContinuousDelivery Hello sir, I am a senior undergrad Comp Sci major and my goal currently is to get a job by the time I graduate in December 2021. I would like to know whether I should be going for learning different tech stacks, CI/CD, Cloud etc. or just get a good GPA and know how to solve data structures problems.
@@visiongt3944 My main advice is to write as much code as you can. Find projects that interest or excite you, play with different kinds of things, maths problems, graphics, little tools to help you do something, almost anything. Next I would advise that you learn TDD, watch a few of my videos on that topic, I hope that they may help, but also pick a 'coding kata' to practice. Take a look here for some inspiration cyber-dojo.org/ On tech-stacks, I don't think that should be very important, however, there are lots of orgs that aren't very good at interviewing and so all they go on is a check-list of tech. That is a terrible way to interview anyone, but particularly bad for people just starting out. If I were in your place now, knowing what I know, I would treat that as a bad sign for that employer, but, being pracgmatic, getting your first job is hard and so you may have to play that game. My advice though, don't treat them like a collection, pick tools and tech that you like working with and get good with that. You can look at what sorts of tech are popular in places where you would like to work, or just pick the most popular things generally. Python and Java and Javascript are popular, but it does depend on what you want to do. As for frameworks or platforms, I wouldn't worry too much about that, most orgs will use a few technologies and it will be hit or miss if you have the ones that they use. Also they are ephemeral, they will change all the time through your career. The skill that you will/should develop is the skill to learn new ones. You get that from doing real work and thinking about what is happening in terms of design, not just the sytax of the use of framework A over framework B. Take a look at this for thinking about languages, dzone.com/articles/top-10-most-promising-programming-languages-for-20 but first get comfortable with one (oh and with TDD 😁 😎).
The longest function I have encountered while refactoring legacy code was around 3000 lines of code and had around 20 parameters. 700 lines of it were nearly exactly copy&pasted within the same function with minimal change.
After all my years, I still don't see why I should break up big hunks of code. If you've got duplicate code then, yeah, that's no good. But if it's proper code that isn't repeated, I've got no problem with it as it saves me from having to jump around in the code. It doesn't seem any easier to maintain but maybe that's because my errors nearly always give me the line number where the break happened? If it weren't for those, finding the 'object not set' error in the 500-line Init() routine would certainly be a nightmare. P.S. When you said the if statement was 100+ lines long, I thought you meant the actual logic portion, not the block of code. I about had a heart attack!
Because it's divide and conquer. It's a lot easier for nasty bugs to hide in huge hunks of code than it is in small single-purpose bits. It's also easier to scroll ignore and scroll past details you are not interested in because they will be one-line landmarks in your code rather than the actual 20 line calculation or whatever.
The DocBlock comment example is a bit dishonest. DocBlock-style comments are used for documentation, not comments. It's good practice to provide explanation of APIs for consumers. It's used to provide context and understanding what is to be expected from using it. Although they shouldn't explain implementation details-as that can get outdated very quick-it should explain generally what it does, and how the input and output is related (e.g. if it has any side-effects, etc.)
Also makes it hard to understand if there is a 9 month break between the last time you looked at it and now. I use human readable variable names for future me coming back to code I wrote a year earlier. :)
combining your first and second tip: if you find yourself separating your code into blocks with little comment headers, that's a perfect opportunity to turn those comments into function names.
Check out the video series object oriented programming is bad by Brian Will. He has a few good points on not breaking up code into tinier pieces unless necessary
I also try to make my functions/methods as short as possible, but sometimes it might be better to write longer methods for redability. It's not a good thing if you always have to look up some method, which is just used in this one method and does not even make sense in a different context, and then just go back to the original method.
If you have method or function names that stop making sense in the context in which they are called then you might have a naming problem. Either the name does not tell the story of what the Client caller can expect from the function or the story it tells is too abstract or not concrete enough. This is where an understanding of the Client-Supplier relationship comes into play. The Supplier methods and functions need names that tell the story of what they require to run and what they ensure they will produce for the Client caller. If the name reveals that relationship well, then you are hitting the sweet spot of proper naming! Context is also important. Having a receipt.add_product vs inventory.add_product vs order.add_product vs quote.add_product-there are different stories. One might need an abstract parent version of "add_product", where inherited versions rename the method based on the context of the inheriting class.
@@LarryRix I didn't talk about function names not making sense in a different context, but the function itself being so specific, it would only be used in the one place anyway. I don't get, what the rest is about. I didn't even mention inheritance.
On the topic of comments, my experiences make me appreciate comments that: 1. Provide me any context that's not obvious yet - what was it orginally designed for, what features were left out (and which would be reasonable extensions that just weren't necessary yet at the time?), what seperates it from potentially similar looking functionalities that could appear elsewhere? 2. Explain the function of the code of low level stuff that's annoying to decypher - yes this is the style of code we're told to avoid, but it's often just unavoidable somewhere. It's fine as long as it's properly capsulated and explained. Ideally we should never have to go to these places, but sometimes we do and then it's nice to have some guidance. This is also exactly the place where comments can help during the original development. The absolute worst is this auto-generated crap that just repeats the literal level: "public bool AutoF {get; set;} //public bool property AutoF". Especially in software that is full of jargon that new coworkers will need to ask otherwise.
I agree about many parameters. You should pack multiple related parameters into structs. For example a vector instead of (int x, int y), especially if you have multiple of them. Same for structs/classes with many fields: If some belong together, pack them into a substruct, especially if you might need multiple of them.
Once I heard from my more experienced colleague simple rule which I use until today: function should easily fit one screen (lenght). I use it until today as an indicatior that I should modify function I am working on
Having a long method that solves one problem. What is the alternative? To use global variables to avoid passing too many parameters. And then if you check for bugs you still need to walk through many methods to find the bug. That will be a big mess. I separate only if it is reusable and/or if it is duplicate. And sometimes duplicate may force to pass many parameters, and I hate that, but has to be done. It reduces the code size to 20% of its original size. Yeah. I truly dislike those branched IF. But sometimes they need to be there.
+37 on reducing duplication, and shortening arg lists. As to the first 3 points, I see the seeds of truth behind these ideas, but I'm not sure I'd take them the same direction, exactly. Take function length. When is a function too long? Arbitrary limits like 20 lines simply push the problem into a different dimension, making many of them too divided up. I think what you're really trying to get at is when a *concept* won't fit in the normal area of vision -- so long that it goes off a page and can't be all seen at once, and/or so wide that one can't see an entire line in one glance. Next take comments. The real value of a comment is to explain anything surprising and anything that can't be grokked faster from the code itself. Repetition is not a virtue. If your args are already typed, you don't need to say any more. If an arg is a percentage, that part is clear; what isn't clear is what it is a percentage OF, and why we care. Also comment-worthy is who might call this function and why, if it's not already obvious. e.g. "def cosine (radians)" computes a cosine of a value entered in radians, not degrees. It's usable anywhere so it needs nothing else unless it is imprecise, e.g. a 256 value lookup that rounds to 3 places and ruins any results needing more than 10 bit precision. Then variable names. Shortest is sweetest until you have to spend time guessing its meaning and use. This ties into my function length comment because x, y, and z are exactly right if you are talking 3-D rectilinear coordinates, and adding verbosity only serves to make lines longer and harder to read. There is a balance, of course, but the optimum is usually closer to the short end. There are other points, but I'd say the biggest is to dispassionately re-craft your code as often as possible to chip away anything that's not aiming at the goal.
Surely you're not seriously suggesting that the cryptic: double hypotenuse(double a, double b) is easier to understand then the self explanatory: double getLengthOfSideOppositeToRightAngleOfARightAngleTriangle(double length_of_side_1_adjacent_to_right_angle, double length_of_other_side_adjacent_to_right_angle)
I had to work on a codebase which had all the mentioned problems. It was tier 1 service and codebase was in such a state that refactoring was impossible without significant development and testing effort. Continuous refactoring is so underrated in my opinion.
Refactoring is simply spinning your wheels. Every time you do, you are spending time on fixing mistakes that crept in at the architectural level on the code level. Oh, wait... there are no mistakes on the architectural level, right? You never had an architect to begin with. You simply began coding without any top-level structure in mind. That's why you keep refactoring.
I find the presentation excellent, but I believe that an arbitrary size check has many downsides. Make the solution as simple as possible, but not simpler than the problem requires. I see separation of concern as my #1 tool: divide to make each problem simpler. However an extensive split of code may cause the graph of methods (and classes) to become the implementation's complexity. The art is to find a balance between the two. Each method should leave the object in some consistent state, which may mandate a minimal size. I have seen code where methods were an incomplete action, co-dependent with other methods, for the sake of shortening each one. This is the quick and easy way to meet, or game, a (deceptively reassuring) mechanical size check. Otherwise, I try to limit myself to one screen page: code that you can see all at once is easier to maintain.
I like comments (in moderation) , but now include a readme.txt file with some simple process, structure or other documentation which is very useful for getting to the right place quickly. Self-documenting code is a nice idea but almost always needs additional context/ clarification/ knowledge, and you don’t necessarily get the option to “look at some better code”, you get what you get, and demo examples are usually ridiculously simplified.
Write Forth. With every repetition, every IF..ELSE clause there is a stack accident waiting to happen. That'll learn you to write well-factored code. ;-) Use tables with function pointers. That takes the heat out of complex logic - it works as a dispatcher. As a matter of fact, my own Forth compiler is built on three tables. Adding a command is as easy as adding an entry to a table. I used the same techniques when writing a Basic interpreter in Forth and recently I could take out the entire GC module and replace it with a new one as easily as changing an engine. Just bolt the thing to the chassis, hook it up to the transmission and you're done. Worked first time.
Thanks for the tips / information. I have mixed feelings about the topic. I want to share my point of view, maybe that helps someone thinking like me: I hardly find bad code that is well documented/commented. Either it's good and documented or bad and not documented (bad in terms of long functions, names like x,y,z and repeated stuff). Even the one you show isn't commented. Also, in most libraries/frameworks, all members are commented/documented (annotations) (like in C# the XML-comments). They really help when trying to use the API/system, and most languages ask/want you to do it like them - so are those excluded for your advice? I think comments/documenting should concentrate on API and everything that others can see and need to see, but not on implementation details (like lines of codes). Important is that the information is never ONLY in the comments, but repeating the info should not be bad. Since they are just comments, you can easily remove/ignore them later. For me personally, I like to comment, it's fun and it helps me to code and to read later (especially in scripting and "main functions"). I also disagree that just reading the prototype of "displayPercentage(...)" is more obvious than the comment saying "Displays the the specified percentage 'p' of the supplied value 'v'." The name of the function isn't clear enough. For me, if you want to do this, you have to go full way (displayPercentageOfSuppliedValueV(...)). But that hardly happens, at least in my experience. Lastly, the thing I don't get is why everyone who wants to code suddenly wants to develop instead? "Our job as programmers is to solve problems, not to write code" But when you begin coding or ask yourself why you started coding, I think many will tell you that they just like to write code - and not thinking about refactoring and naming things to become a system. I don't think that we can ignore why it's called "coding" in the first place and not "problem solving".
I have to disagree on the last point you make. I don't think I have ever met anyone who's said "I like coding" and meant that they just like pushing keys on a keyboard. Much the same way someone who says "I like woodworking" doesn't mean they like using a saw to chip random blocks of wood off a trunk. Coding, by necessity, implies some degree of thought about the quality of what you are typing.
This felt a little like reading our checkstyle and pmd configuration which we use in our Java projects. Unfortunately, we do not have similar comprehensive check tools for C and Fortran, but in case someone knows some tool, let me know. One other point: Usually, when I inherit code from others, I start reading it and in the process I usually refactor it. The only thing I am not doing extensively is TDD which is impossible when you inherit code from others, but also in my own work. However, I will improve in that area ;-)
The best channel, for development - I recommend the book "Clean code" it is really nice for targeting the problems listed in this video. You can find the book online in pdf version.
I agree with everything except the max 20 lines per function. I develop a web system in php and I try to follow the tips in this video, since I started developing more than 20 years ago as a teenager. But: In the system I currently develop, there are functions of hundreds of lines of code, that functionally belong together, without repeating patterns (if there were, I would have them extracted into functions by now). Splitting these functions up, would just cause dozens of parameters on every function, as the code is so interconnected. In general, these are functions, that create part of the output page of the web system, but also data analysis or data restructure algorithms can get very lengthy.
Well, if a method needs many parameters, make it a class. 20 lines of code for a method is still too long if you're talking about clean code. Saying that splitting the code into functions would cause too many parameters is nonsense. Just apply the "extract method" refactoring technique.
@@Edouardkick believe me, if you knew the code I am working with, you would agree with me, that what you are saying simply isn't applicable to the code. There is no way to make it 20 lines or fewer without ripping apart code that functionally belongs together. We are not talking about low level functions or algorithms. Those, I agree, can be quite short without issues. I am talking about code that is processing thousands, if not millions of lines of data into a readable format in a web browser. That includes charts, diagrams, tables and so on, all of which need at minimum 20-30 lines of configuration before they are even displayed. And yes, that does include putting the settings into classes, but that still requires lines of code!
Thank you very much, Dave, for sharing your knowledge and for the awesome content of your channel. You make your points in a very light and comprehensive way, and put our minds to work along your argumentation. Very well explained and reasoned. Once again, thank you and keep up the excellent work, I'm looking forward to more content. Best regards, from all across the Atlantic ocean!
Great advice, but there's one thing missing. How to talk your boss into accepting the time usage of building half-decent code instead of quick and dirty solutions with endless klocs of repeating crap that becomes an incomprehensible mess about three days from when it was finalized? Particularly if your boss "use to" do "some programming", it really can be a PITA to get a reasonable time allotment to get the job done right. Sure, it will save problems "in the future", but who knows when that future will be? Who knows who is going to be the boss responsible at that time?
In a perfect world: Explain them how cost of change goes up if code is not maintained/clean. That productivy will go down and therefore their costs for new features goes up. In reality it will be easier to just increase your estimates on your tasks and use the extra time budget to do refactoring.
Hi, I love your video, you helped me and my team improve our velocity a lot, thank you. I found myself to partly disagree about long functions, I do agree that long functions the vast majority of time are code smell and are long with no reason (probably because of duplication and not following CRP) But there is no one length that I find functions to be "bad" from, and I will always prefer reading code vertically than horizontally. In some application, its just make sense to have a "flow" function, one that is just doing stuff sequencially in one after the other, in my experience those function never reach 200+ lines without code smell. But I finds the practice of extracting to one time (private) functions that do not hold any domain by themselves make the code even harder to read. In one function at least the order of read is similar to the order of execution. Some people suggests to implement some design patterns like fluent code but I find it not worth it to use an abstraction for one time use as I tend to build abstraction only when I fine that I need them ( probably if a code became a repeating patttern )
Suggestion: 1. Extract to 30 lines of code or less. 2. Name the functions verb_adjective_noun() so that it is easy to read. I like to only have one function per file, with the name the file the same as the function. Each directory is a separate namespace. In the directory, you can see the code "folded". 3. Make one function that calls the other functions in the correct sequence.
I only comment: * functions/types I defined, if the name is not obvious (or if I use them to generate documentation, also the obvious ones) * difficult segments, mostly math, which I often forget myself * things that seem like some mistake, but actually have to be this way ("don't remove this assignment. It does not just redefine an existing variable, but accessing the original variable implicitly invokes a non-performant calculation")
Not sure if a similar comment was already made to this video about code-quality, but here goes: When writing code, always keep this in mind: Code is written to be read by *humans*! Not by computers! Compilers throw away the code you've written and produce binary garble to be consumed by computers. If code were just for computers, we would still write all code in binary or punch cards :)
I agree on 4 of the ways to improve code, but not on the long methods. I see much code with many small functions where I have to jump around from the code in one function to the other in attempts to try to understand what those functions do. It would be much faster if I had the code inline. I prefer to have one long function in that case. With blocks of code preceded by some comment adding info about what the purpose is, maybe in more words than a function name.
I prefer to look at it in terms of structure than lines of code. It does sometimes happen that you really do just have a simple, uniform sequence of many steps... no loops, no conditionals, etc, and in these very occasional cases, sure, I'd agree that leaving it all in one function would be most appropriate. But once you start to get multiple loops and / or multiple conditionals, then no, these need to be split into multiple functions. In most cases a section of code with its own conditional and loop is typically something that should be pulled out and identified as its own clearly defined function. Having multiple such sections of code aggregated into a single 'big' function runs the risk of the 'global' variable problem - i.e. what should be local variables, effectively become global, because everything is all in the same local scope. Variables you define for the first part of your long function will still be in scope for the next sections, which isn't good practice, etc. More generally, long functions that haven't been broken into smaller functions is usually a sign of an inexperienced programmer who hasn't yet fully grasped the need for, and challenge, of properly architecting software. If you have multiple loops and conditionals that you feel you need to have all grouped together in a single large function that you feel doesn't naturally break down into smaller natural functions (and most likely classes as well) of their own, then you probably haven't fully understood the problem that you're trying to solve.
About refactoring: I do not think about "refactoring" as a separately identifiable knowledge to be learned. You learn what good code is. You learn what bad code is. You learn what isomorphic transformation is. Now you now everything. If you find a bad code, you turn it into a good one. The refactoring step in TTD is not different in any way.
Mostly I agree, refactoring isn't, or shouldn't be, a separate thing. But I meet a lot of programmers that don't think about it and are scared to change code. Sure, that usually means that they don't have enough tests, but also there are lots of changes that I comfortable making, in confidence that I won't break anything making them. So learning some of the small steps, the techniques, of refactoring from something like Martin Fowler's book (amzn.to/30ntgaK) is a good idea.
@notinlist I respectfully disagree that refactoring is not a separate thing, there is inherent complexity and craft in choices made for stepwise refactoring to minimize effort and risk, especially when tackling code that requires more work or crosses current test boundaries... Knowing what you dislike currently and the end state you'd like to get to does not come close to covering this optimally, imho. In my experience as a pair, many people who are not yet well practised in refactoring struggle at times, to the extent of failing slowly and requiring reverts on early attempts.
1. Your code will never be better than the data model on which it is based. 2. Well-written code tells the reader what the code does, but cannot tell the reader what the code is supposed to be doing. Comments are required to supply this information. 3. Let each function perform one task. 4. Let each task be performed by one function.
I have to admit that the first time I jeard some advices for code I did not u derstand the reasoning behind some of them until it was obvious while practicing. For exampke, the 22 parameter function, an advice would be to wrap them in an object, at first this sounded like extra code to me, but now generally the objects that hold those parameters are already there to be used
My comments are documentation. I have a memory issue (like damaged RAM chips under my skull), so unless I document my code it's not very useful to me. Documented code provides code completions and popup descriptions that allows me to use the module in real projects without depending on my broken memory. The documentation of each module contains what is it for and how to use it. I know it can be reverse engineered by just analyzing the code, it's self-explaining, however it takes too much time. Code completions and popups in VS are way faster. Sometimes during writing the documentation I realize that something is wrong about in my interface or whole design and I change the code to be more usable from the interface side.
Yep. And no matter how easy it is to follow the code, the code doesn't tell you WHY you did it that way. I have code with comments like this: _//I know this looks silly and redundant but it's necessary to avoid a memory leak in the constructor of class z in the xyz library_
@@oldcountryman2795 I agree. That's the exception that comments other than documentation are useful. I sometimes add something like FIXME or TODO or HACK tags to revisit the code later and fix the thing so it wouldn't need comments. Usually the cause for weird things in the code is something else (like a library, OS behavior) buggy, when it get fixed you can remove the workaround if you have it documented.
5:00 There is one excuse for long functions/methods that appeared in both in my academic and professional life. That is the core rendering loop. The thing that really determines every pixel. That's not to say that a sprite should be in the same location as the collision detection. Just that very few languages are expressive enough to write small rendering loops. There were red flags in both cases though. 1. It was really hard to balance where new code should live. 2. Often the loop became "god code", something that should not be modified, especially by the uninitiated. 3. It was very difficult to follow the mutable state through even just one iteration of the loop.
a) Code comments in "repeation" style may bore out the reader & distract from important & problematic parts, thus better keep the Dont Repeat Yourself-Principle. b) Code comments in "teaching style" may help yourself & colleages in unfrequent changed/reviewed code base e.g. already finished/delievered customer projects or stable systems core. c) Code comments can be reduced if they reference to external description (documents/database entries): requirements, specifications, design, implementation (doxygen), issue tracking, FAQ, readme, installation, testing. That way the context can be given w/o much duplicate code comment copies, a good searchable intranet/content management system helps finding external information. d) Code comments may be deleted if they refer to changes -> shifted them to well disciplined VCS checkin/commit/submit commenting.
I'm using C++ for my project for a bunch of reasons that I won't bore you with. I'd like to write short functions, and I'd like to refactor into smaller functions, but it's just so bugsome to have to write a declaration in a header file for every single little function. And I hate having headers that are chalk full of all these little tiny functions. I just want the header to show the top level functions. All the little private functions that the top level functions call should not be in the header file. They're just clutter at the header level. But C++ won't let me program that way. I have to create header declarations for all those little private functions.
I thought I had seen some real turds before but a function with 623 lines of code? 22 arguments? 300+lines of code inside an if? Holy shit. Great video and channel!
Interesting, I try to do most of the stuff you mention but I need to try harder. Re tdd: I got into programming mainly writing stuff for academic research, no time there for writing test code as the purpose of the sw changes every day. To this day I only do integrated testing but try to test everything in the codebase through a range of integrated tests.
@@LPFan33 Not if you your code is well organised. When I make changes I know exactly what final ouput they can influence,. Side effects happen sometimes if the code change affects processes at the same level as those for the target for improvement. So I test related output at that level (integrated tests if you like). The number of outputs that could be affected by a change should be very small:
The senior developer is not onto you. He might have issues with your code, which is not unexpected, if this is your first position as a professional software developer. Even if you're very talented, learned a lot in school and started to program early in life and have hence some practice, there are some experiences you are unlikely to have made if you haven't maintained code over an extended period in a team. Try to engage that senior developer, ask him what exactly is wrong and why and how to improve the code. Try to learn the most you can, that's what the internship is about.
I always say that rule #0 of a clean code development is: "make the life of the fellow developer easier". All the others are derived from this. Rule #0.5 is "be consistent". If, at some moment somebody else (not you, of course!) did a sh*t and you don't have the time to fix it, then either use his sh*t or create your own similar sh*t AND create a new working item for future: "fix the sh*t". When it comes to comments is easier: if, in the middle of a method you feel the need to put a comment to explain what are you trying to do, don't put the comment! Extract a method instead.
7:40 question about "Cyclomatic Complexity"; if I have an If condition that reads like if(Thing1 == null) return; is this alternative more readable? if(Thing1IsEmpty) return; Or am i overengineering at this point?
I follow most of the things talked about in here except long code in a single function. If I don't have duplicate code, I don't make a new function. But still I follow the rule that a function should do a single thing. Sometime that single thing requires lots of stuffs. Like suppose I have to bind 10-15 different class binds to render a single thing. I can make a huge complex system to make the binding process shorter. But that breaks the keep it simple stupid, rule. Also sometimes it impacts performance. I would rather make a huge messy pointer arithmetic, template meta programming filled code, if that is more efficient than short clean code. Also sometimes to make some code shorter you need to write a function with 10+ arguments. Like supposing populating a struct with 10 different members. I would rather do that manually.
2:00, I disagree, because nowadays every command does many things. For instance, if you are searching something in an array, you can put a comment not the kind of "finding something", but for why are you searching that - not technically, but semantically. 2:30, here, I would write a comment about what is 'r', and why it's calculated like that. And I would do that at the right of the line, to avoid growing it downward. 3:45, I think it's not always possible: sometimes it's too intricate, and you will want to break it in parts, even harder to explain. 4:25, a majority of my f()s can be seen entirely in 1 screen. However (6:03), there are some of them that take 3 or more. And their content works as something private, that should not make sense to be exposed to the rest of the project, in a form of other f()s. Of course I'm not talking about reusable things (7:07), but about only 1 goal (7:55) that requires many steps, many initializations, many private and temporary data.
Is having like 6 to 8 parameters in a constructor of an "entity" (class representing a database table) is bad ? Considering that these fields have "not null" constraint. That is the only case where i think it's OK to do so.
Sometimes, what you are passing to your method or function as parameters are really properties of a class you have not yet defined. Long parameter (or argument) lists might be cleaned up by creating classes with those parameters as properties. This puts those properties into a more reasonable context where you can control the state of the object using rules and prove those rules by TDD + BDD. The other solution (of course) is based on the "code smell" that the function or method has a poor "separation of concerns". What is really needed are separate functions or methods, each with their own goal or purpose, and then just the arguments (or parameters) needed to get that job done. The calling code can then decide which methods or functions to call based on its needs as a Client of the others. You might find that the answer to large parameter lists is also a combination of both of the points above-that is-you are missing some class or classes, where the parameters can be properties of them-AND-you have poor separation of concerns as well. One thing that usually happens is that the receiving method or function is far too long (as Dave points out in this video). Therefore, a long method or function ought to be a clear sign that a refactor needs to be done, where new classes and smaller methods and functions will be the result, which will (in turn) reduce the number of method or function arguments being passed around-or at least carve them up and send them to their appropriate handlers!
If OOP, before you refactor into small functions look to see if you can refactor out a new class. Could be that you're trying to do too much in one unit (separation of concerns). A few times now that I've unrefactored functions so that I could extract a new class. That maintaining a connection problem seems a prime candidate. 600 lines in a class seems too large nevermind in a method. BTW, you refactored the "c" out of the word.
If you want good code, give your engineers time to _think_. Do _not_ expect them to sit there and write pages of code. It will almost certainly be sub-optimal and should be thrown away. Often the first draft is nothing more than exploring the problem domain and determining the correct approach. Let them sit and think and experiment. It looks like unproductive time from a PHB viewpoint, but it is very productive in the long run.
I believe function helps to express the intent for the block of statements than acting as reusable component. Reusability is a byproduct of a function, not necessarily a goal.
One can't live like this in some cultures and codebases. If you are in such place: time to go forward - don't learn to tolerate code that you can't change and hate to work with.
Do you fail the build at the commit stage or acceptance stage in the pipeline when running static analysis? I would think it's too slow for the commit stage?
I prefer to do it in the commit stage if I can, so finding tools that can give me that answer fast enough. In Java Checkstyle and Findbugs are a decent start, Lint and Lint-like things are also good. Also, turn up the warning level of your compiler to max, and fail commit if you get a warning.
I find those images of code very difficult to read, they're so small. I'll take your word for what they say, but you could have illustrated the same ideas with cartoon blocks rather that actual eye-straining text. Or you could sacrifice the constant presence of a human figure taking up half the frame.
I sometimes prefer longer methods over (too) many short ones. In my opinion it's often easier to understand and find bugs then in many short ones. But I agree that 623 is too long. But I would also say that 20 lines is a very low threshold. I would probably have it around 50 lines. But that's just my opinion.
For me 20 lines is usually too long. I find most functions work well with 7 lines of code (counting lines that contain alphanumeric characters; brackets don't count). I'm not sure what you mean by finding bugs? Can you explain? I find that with 7 lines of code per function - with each line properly commented - bugs don't have anywhere to hide in the first place. Bugs are something I vaguely remember of the past of 20+ yrs ago.
@@vaibhavarora7782 Yes Lint can be used for JS/TS I guess. For backend there are solutions like Detekt for Kotlin. Probably for many languages, there is something helpful.
Sometimes I feel sorry that no one is willing to pay the extra penny on refactoring. Although this video is so true about refactoring but unrealistic in some situations where you not only inherited bad code, but strict deadlines that leaves you without having the chance to clean the mess.
I confess that I don't really buy-in to the "no time to clean up" idea. I don't think that we should ask permission, I always tidy the code in the area that I am working. Of course you may not have the time, or freedom, to do large-scale changes, but many small, often simple, refactorings can quickly add up to a better codebase.
@@ContinuousDelivery still can't see how would I have time to refactor 300+ lines of code if the job is to change one line of code where it was originally estimated for 1-2 hours. Now I am in the middle between theory and reality.
@@AlaaAlMaliki IMO your job isn't to "change one line of code", ever, it is to work in a sustainable way. Also, don't necessarily change 300+ lines in one sitting, change a few lines in the area of the code that you are working on to make your work clearer, more expresive and better designed. If that requires you to change 300 lines, then maybe your code is very bad and if you change the 300 lines now, you will be going MUCH faster next time you touch that code.
The concept of a deadline is inherently stupid anyway. It's not done until it is done. At best, you can forecast when you expect something to be done. At worst, someone above you in your organization gives you a deadline, increasing pressure on you. Pressure that can lead to lower quality code, possibly even introducing mistakes, on top of increased stress levels which can lead to all sorts of health and behavioral problems.
11:30 "Adopt the discipline of allowing yourself one conditional per function or method." I'm assuming this means 1 if statement. What?! I don't think any of my code could meet this requirement. There are too many places where I need very short if statements looking for error conditions to fix or throw on.
I think that constraint might be a bit too extreme. However, one way to make it work would be to distribute error checking to were it's really needed. If you have
I took that as: limit yourself to one level deep, not necessarily one condition per function. I dont agree with either notion, but the bulk of this video seemed to be reasonable advice, especially on comments!
I have seen a function with 11,000 lines. Several levels of if and switch... But, honestly, also me, 20 years ago: "why should I want to write header files, when I can put everything in one single c-file?" And: "every line of code needs to be commented." How things (and comprehension) have changed by 180° in the meantime...
If you need very complex initialization then a factory pattern is for you. If nothing can be automated about the initialization of 200 parameters, then you know that you are already in hell and you might as well ask Satan for a new assignment in the glowing ember pit. :-)
@@Sergio_Loureiro That was my point. There is a level of complexity, even in initialization, that requires automation. Not sure I have ever seen 200 in my life, either, but I think I have seen something on the order of 50 or 60 in a plot function once. Somebody tried to cram everything and a kitchen sink into that poor function call. It is not all that hard to get to impractical numbers of parameters. Look at GUI elements like buttons, for instance. Location, size, colors for background, borders, highlights, style, fonts etc. It adds up quickly and personally I am becoming frustrated if I have to deal with even a dozen parameters.
@@CynicalOldDwarf it’s not flexible enough. If you don’t do some design work upfront you end up throwing away tests, constantly changing them and in larger terms it becomes a nightmare to manage. Worked with guys who would kick off if you started with a class rather than a method (because no test had been written that meant a class was needed) some of the most dogmatic and terrible developers I’ve ever worked with,
comments: i don't write them unless i think the reader will need information that's not in the code function size: no limit here. i write code in scala which allows nested functions. a function can have 1000 lines but is structured very well
pfff, 623 line function, I had to debug a vb (I know, I know) library, it had 3 functions each of which had 40 params and over 1000 lines; It was essentially the same code in each with a few minor differences too. After refactoring I got it down to 500 lines total in the library in multiple small functions. ;)
Improving your code in this way heavily depends on TDD and CI. You will not have the confidence nor the motivation to change your code if you can break it without knowing it. For example, if you rely on a tester to click on your web page then your code is doomed. What, you think the tester will test everything again just because you want to refactor? And you think you will not break your code when refactoring? Cut it out! That's why Martin Fowler said in his book you must test all your code before you consider refactoring.
"An idiot admires complexity, a genius admires simplicity, a physicist tries to make it simple. An idiot will make everything so complicated you'll think he's a god for understanding it."
-paraphrased, Terry A. Davis
As deranged as he was, these are words to live by, both for designing software and life in general.
RIP based Terry
"The greatest programmer that ever lived"
I'm so glad I found this channel. It's full of gold. Thank you very much for your videos.
Thank you
*5 Ways to Improve Your Code*
1. Minimize the need for Comments, Code should explain what it does.
Write a comment to explain [why you make that choice] rather
explaining [what it does].
2. Avoid Long Methods (Avoid creating long methods it's hard to read, maintain & troubleshoot), prefer short methods over long methods
3. Avoid Long Parameter List (use max 2 parameters)
4. Avoid Duplicated Code (Duplicated code is maintenance overhead)
5. Avoid Complex Conditional code (Avoid large block of code in single condition)
Finally a channel that offers unpaid advice. Just what I need for my new role. I hit that subscribe button faster than anything else.
The biggest problem is that programmers code before structuring and/or understanding the data. On many contracts I am asked why I am not coding. I say I am organizing the data. That does not go over well. I get heat from management. I persist and normally finish with a very stable solution before the allotted time. I have worked on pacemakers, motor control, heat, HVAC, aviation, proprietary RTOSs, search systems and more. I am a very big fan of structuring my data like organized MUD.
As a beginner, for months I've been trying to understand what was meant by clean code or eloquent code, etc. THANK YOU!
There does not exist any rigorous definition of what "clean code" means. It's largely informed by gut feeling, and any attempt to capture the meaning via rules of thumb fails half the time anyway.
Interesting, that helps orient my mind properly on this subject, thank you for your reply.
@@ubercorey No problem. :-) This field is extremely opinionated, so always asking why and putting serious thought into peoples answers will cut through most of the bullshit. For example, the fact that Continuous Delivery uses science and statistics to inform his opinions, means he should be listened to. Also, be very suspicious of any dogma.
Personally I try to avoid using nebulous words like clean. I try to find more precise words to convey what I actually mean by clean. For example "this code is easy to read/understand" or "this code is easy to edit" or "this code follows my organisations best practices" rather than "this code is clean".
I have absolutely noticed that about your way of speaking and teaching.
Use the scout rule - leave the code better than you found it. :)
Yes
@@ContinuousDelivery I agree, but wow are there office politics to be considered, too. I had untold trouble even when I could (actually ESPECIALLY when I could) prove that I improved code. Some co-workers don't like that, and coding is often a social endeavour.
@@ericpmoss exactly. when the product owner moto is : if it ain't broke don't fix it, you are not allowed to touch any line of code that are not directly impacting your functional changes.
I also like that one: "Make the change simple, then make the change". So refactor before making a change. But don't forget to do it in separate commits!
I thought it's "bury your shit in a hole in the ground"
Comment every line! And I mean every line. I learned this the tough way from a colleague in my first software engineering job. I hated his code for it; I kept repeating to him, like you, that code should be self commenting, etc, and coming out with all the arguments against comments that we all know very well. But after 3yrs working with him (back then) I couldn't deny an unavoidable truth - his code never, and I mean never, not once, had a bug in it! How could I tell this programmer what to do, when I couldn't say the same for my code. That was tough for me to admit. But I opened my eyes, and had a go at copying his style, commenting every line ... like you say, it's important to comment sincerely, not just flippantly saying what the syntax is doing ... and to my amazement, overnight, I went from producing typically buggy code like most programmers, to producing completely bug free code just like the guy I was now copying.
So what gives? What is making the difference? It's quite simple, and became abundantly apparent once I tried it. Pedantically commenting *every* line (when done sincerely, and *not* simply describing the syntax, etc), makes sure that you know what you are doing, and acts as a comprehensive self-review. It sounds like "well, durh!!" but I subsequently found it amazing how often I'd write a line of code, go to write the comment above it, then realise "ah, hang on, that's not quite what I intended to do", or realise a subtle short coming with the algorithm I was writing, etc. Often even going back to completely re-write the function when I suddenly realised the whole function wasn't doing quite what I intended, or that it might be subject to problematic edge cases that I hadn't thought of when I set out writing the function, but that had then sprung to mind when writing the comments. Even simple lines like incrementing a counter (index++). Once you come to write a meaningful comment for that increment, for example "move to the next element in the zzz list" (or whatever the context)... that prompts you to think... "ah... but what if we're now past the end of the array? have I put the check in?". And so on. All of this being identified and realised before the code has ever been run, not even from the development environment.
And commenting every line, forces you to make sure each line has a clear, simple role. If you have a complex line that's doing a lot, then commenting every line forces you to break it up.
And that often also reveals problems with that code that you'd written. It's funny how typically the most difficult lines to comment in this manner, are the ones where you're not really sure what you're doing. Pedantically commenting every line means there's no hiding! You can't get away with just writing a line of code in the 'hope' that it's probably correct. If you can't write a meaningful comment above a line, if you're being honest with yourself, it's usually because you don't *really* know what you're doing, and realistically you need to re-think it until you do know what you're doing.
A professional programmer should not need to step through a section of code they are writing on the debugger in order to evaluate what it's doing!! A professional programmer should confidently know what each and every line of code will do when they write it!! For that professional programmer, commenting every line of code, at the time of writing, is easy.
In fact, that's probably a good guide for programmers to self-evaluate how far they have come as a professional. If you are able to comment every line of code, meaningfully, as you write it, that's probably a sign of a good, experienced professional. The programmers you should be concerned about are the ones who can't - and therefore obviously won't - buy into this approach.
I've subsequently had lots of arguments with colleagues who think I'm just a thick, dumb idiot for doing it. The majority throwing the same arguments back at me, that I used to throw at that original colleague all those years ago. Some try to setup code style rules to prohibit it.
But I always have one challenge for them. I say I'll listen to you, if you produce code as bug free as I, and that original colleague, do. In the 20 yrs since I learned this technique from that original colleague in my first job, no subsequent colleague has yet met that challenge - though a number have listened and observed, and tried this approach and become converts.
Ironically, some of those I've argued this with over the years have also argued quite vociferously that (and I quote one them) "Software is always buggy!". They don't believe you can write bug free code. They refuse to believe you. And refuse to even give it a shot. They believe they are right - that software is always buggy - and, in practice their own code invariably reinforces their claims!
oh god. I couldn't even finish this comment, it's almost as if you commented every line in your comment. If you need to write comments to evaluate what you've coded, where the hell are your unit tests?
TL:DR
"If you're really good you're allowed to have an else clause as well" hahah subtle but made me laugh
😁 😎
@@ContinuousDelivery Hello sir, I am a senior undergrad Comp Sci major and my goal currently is to get a job by the time I graduate in December 2021. I would like to know whether I should be going for learning different tech stacks, CI/CD, Cloud etc. or just get a good GPA and know how to solve data structures problems.
@@visiongt3944 My main advice is to write as much code as you can. Find projects that interest or excite you, play with different kinds of things, maths problems, graphics, little tools to help you do something, almost anything.
Next I would advise that you learn TDD, watch a few of my videos on that topic, I hope that they may help, but also pick a 'coding kata' to practice. Take a look here for some inspiration cyber-dojo.org/
On tech-stacks, I don't think that should be very important, however, there are lots of orgs that aren't very good at interviewing and so all they go on is a check-list of tech. That is a terrible way to interview anyone, but particularly bad for people just starting out.
If I were in your place now, knowing what I know, I would treat that as a bad sign for that employer, but, being pracgmatic, getting your first job is hard and so you may have to play that game. My advice though, don't treat them like a collection, pick tools and tech that you like working with and get good with that. You can look at what sorts of tech are popular in places where you would like to work, or just pick the most popular things generally. Python and Java and Javascript are popular, but it does depend on what you want to do.
As for frameworks or platforms, I wouldn't worry too much about that, most orgs will use a few technologies and it will be hit or miss if you have the ones that they use. Also they are ephemeral, they will change all the time through your career. The skill that you will/should develop is the skill to learn new ones. You get that from doing real work and thinking about what is happening in terms of design, not just the sytax of the use of framework A over framework B.
Take a look at this for thinking about languages,
dzone.com/articles/top-10-most-promising-programming-languages-for-20
but first get comfortable with one (oh and with TDD 😁 😎).
@@ContinuousDelivery Great advice Dave. I'm just starting out in software engineering and this is extremely useful. Many thanks from a fellow brit!
@@hi3694 Thanks
The longest function I have encountered while refactoring legacy code was around 3000 lines of code and had around 20 parameters. 700 lines of it were nearly exactly copy&pasted within the same function with minimal change.
This video is another jewel from Continuous Delivery. I've seen about half a dozen of your videos and so far all of them are brilliant. THANKS!
Couldn't agree more. It somehow reminds me of "The Pragmatic Programmer" by Andrew Hunt and David Thomas.
After all my years, I still don't see why I should break up big hunks of code. If you've got duplicate code then, yeah, that's no good. But if it's proper code that isn't repeated, I've got no problem with it as it saves me from having to jump around in the code. It doesn't seem any easier to maintain but maybe that's because my errors nearly always give me the line number where the break happened? If it weren't for those, finding the 'object not set' error in the 500-line Init() routine would certainly be a nightmare.
P.S. When you said the if statement was 100+ lines long, I thought you meant the actual logic portion, not the block of code. I about had a heart attack!
Because it's divide and conquer. It's a lot easier for nasty bugs to hide in huge hunks of code than it is in small single-purpose bits. It's also easier to scroll ignore and scroll past details you are not interested in because they will be one-line landmarks in your code rather than the actual 20 line calculation or whatever.
The DocBlock comment example is a bit dishonest. DocBlock-style comments are used for documentation, not comments. It's good practice to provide explanation of APIs for consumers. It's used to provide context and understanding what is to be expected from using it.
Although they shouldn't explain implementation details-as that can get outdated very quick-it should explain generally what it does, and how the input and output is related (e.g. if it has any side-effects, etc.)
3:05 Also code like this, with single letter parameter names makes it hard to search for variable names or even search and replace automatically.
Also makes it hard to understand if there is a 9 month break between the last time you looked at it and now. I use human readable variable names for future me coming back to code I wrote a year earlier. :)
combining your first and second tip: if you find yourself separating your code into blocks with little comment headers, that's a perfect opportunity to turn those comments into function names.
Yes
Check out the video series object oriented programming is bad by Brian Will. He has a few good points on not breaking up code into tinier pieces unless necessary
I also try to make my functions/methods as short as possible, but sometimes it might be better to write longer methods for redability. It's not a good thing if you always have to look up some method, which is just used in this one method and does not even make sense in a different context, and then just go back to the original method.
If you have method or function names that stop making sense in the context in which they are called then you might have a naming problem. Either the name does not tell the story of what the Client caller can expect from the function or the story it tells is too abstract or not concrete enough.
This is where an understanding of the Client-Supplier relationship comes into play. The Supplier methods and functions need names that tell the story of what they require to run and what they ensure they will produce for the Client caller. If the name reveals that relationship well, then you are hitting the sweet spot of proper naming!
Context is also important. Having a receipt.add_product vs inventory.add_product vs order.add_product vs quote.add_product-there are different stories. One might need an abstract parent version of "add_product", where inherited versions rename the method based on the context of the inheriting class.
@@LarryRix I didn't talk about function names not making sense in a different context, but the function itself being so specific, it would only be used in the one place anyway.
I don't get, what the rest is about. I didn't even mention inheritance.
To add to the chef analogy: You don't want your "oranges à vif" to taste like garlic just because you did not clean your knive.
Ahh, separation of concerns for chefs - I like it! 😎
That sounds delicious.
"I don't want salmonella because you decided to cut the chicken and vegetables on the same block", probably an easier to understand example :)
@@CynicalOldDwarf Maybe, but a little crazy. Most learn very early to separate the two, completely. Not so much in coding.
@@CynicalOldDwarf I don't want both my chicken and potatoes mashed. Send my potatoes to the masher and the chicken to the oven.
On the topic of comments, my experiences make me appreciate comments that:
1. Provide me any context that's not obvious yet - what was it orginally designed for, what features were left out (and which would be reasonable extensions that just weren't necessary yet at the time?), what seperates it from potentially similar looking functionalities that could appear elsewhere?
2. Explain the function of the code of low level stuff that's annoying to decypher - yes this is the style of code we're told to avoid, but it's often just unavoidable somewhere. It's fine as long as it's properly capsulated and explained. Ideally we should never have to go to these places, but sometimes we do and then it's nice to have some guidance. This is also exactly the place where comments can help during the original development.
The absolute worst is this auto-generated crap that just repeats the literal level: "public bool AutoF {get; set;} //public bool property AutoF". Especially in software that is full of jargon that new coworkers will need to ask otherwise.
There's not a single video of Dave that I don't find interesting or educational. I'd love to meet him some day.
This video is so good, I'm embedding it in our onboarding flow.
Thanks
I agree about many parameters.
You should pack multiple related parameters into structs.
For example a vector instead of (int x, int y), especially if you have multiple of them.
Same for structs/classes with many fields: If some belong together, pack them into a substruct, especially if you might need multiple of them.
Once I heard from my more experienced colleague simple rule which I use until today: function should easily fit one screen (lenght). I use it until today as an indicatior that I should modify function I am working on
Yes, that is a good guide, automating the check is even better, trust but verify😁 😎
@@ContinuousDelivery That's for sure. I benefit from the colleague's rule for 10 years but I have never got idea to automate it ...
Everything as code! 😀
Boss, for this new project I will need that 32:9 portrait screen
Bit disappointed the first improvement wasn’t “write less code”. ;)
It's pretty much the bi-product of this video.
I'm really pleased it was about pointless comments. universities are still teaching BAD practices
Having a long method that solves one problem.
What is the alternative? To use global variables to avoid passing too many parameters. And then if you check for bugs you still need to walk through many methods to find the bug.
That will be a big mess.
I separate only if it is reusable and/or if it is duplicate. And sometimes duplicate may force to pass many parameters, and I hate that, but has to be done.
It reduces the code size to 20% of its original size.
Yeah. I truly dislike those branched IF. But sometimes they need to be there.
I am glad I found your channel. Very clear and to the point explanation of not very simple problems !
These have been very good ideas for a very long time. In the paleodev era your second was "never cross a perf"...
+37 on reducing duplication, and shortening arg lists. As to the first 3 points, I see the seeds of truth behind these ideas, but I'm not sure I'd take them the same direction, exactly.
Take function length. When is a function too long? Arbitrary limits like 20 lines simply push the problem into a different dimension, making many of them too divided up. I think what you're really trying to get at is when a *concept* won't fit in the normal area of vision -- so long that it goes off a page and can't be all seen at once, and/or so wide that one can't see an entire line in one glance.
Next take comments. The real value of a comment is to explain anything surprising and anything that can't be grokked faster from the code itself. Repetition is not a virtue. If your args are already typed, you don't need to say any more. If an arg is a percentage, that part is clear; what isn't clear is what it is a percentage OF, and why we care. Also comment-worthy is who might call this function and why, if it's not already obvious. e.g. "def cosine (radians)" computes a cosine of a value entered in radians, not degrees. It's usable anywhere so it needs nothing else unless it is imprecise, e.g. a 256 value lookup that rounds to 3 places and ruins any results needing more than 10 bit precision.
Then variable names. Shortest is sweetest until you have to spend time guessing its meaning and use. This ties into my function length comment because x, y, and z are exactly right if you are talking 3-D rectilinear coordinates, and adding verbosity only serves to make lines longer and harder to read. There is a balance, of course, but the optimum is usually closer to the short end.
There are other points, but I'd say the biggest is to dispassionately re-craft your code as often as possible to chip away anything that's not aiming at the goal.
Please, define "too divided up" and give an example.
Surely you're not seriously suggesting that the cryptic:
double hypotenuse(double a, double b)
is easier to understand then the self explanatory:
double getLengthOfSideOppositeToRightAngleOfARightAngleTriangle(double length_of_side_1_adjacent_to_right_angle, double length_of_other_side_adjacent_to_right_angle)
Thanks for sharing this informative video! Keep up the good work!
I had to work on a codebase which had all the mentioned problems. It was tier 1 service and codebase was in such a state that refactoring was impossible without significant development and testing effort.
Continuous refactoring is so underrated in my opinion.
Refactoring is simply spinning your wheels. Every time you do, you are spending time on fixing mistakes that crept in at the architectural level on the code level. Oh, wait... there are no mistakes on the architectural level, right? You never had an architect to begin with. You simply began coding without any top-level structure in mind. That's why you keep refactoring.
I find the presentation excellent, but I believe that an arbitrary size check has many downsides. Make the solution as simple as possible, but not simpler than the problem requires. I see separation of concern as my #1 tool: divide to make each problem simpler. However an extensive split of code may cause the graph of methods (and classes) to become the implementation's complexity. The art is to find a balance between the two. Each method should leave the object in some consistent state, which may mandate a minimal size. I have seen code where methods were an incomplete action, co-dependent with other methods, for the sake of shortening each one. This is the quick and easy way to meet, or game, a (deceptively reassuring) mechanical size check. Otherwise, I try to limit myself to one screen page: code that you can see all at once is easier to maintain.
This tips come naturally to Coders with bad OCD ...
Comments are useful, simply as visual markers. Also, it's a pipe dream to say 'write self-documenting code. Code can never replace comments.
Sorry, but I think that you need to look at some better code.
I like comments (in moderation) , but now include a readme.txt file with some simple process, structure or other documentation which is very useful for getting to the right place quickly.
Self-documenting code is a nice idea but almost always needs additional context/ clarification/ knowledge, and you don’t necessarily get the option to “look at some better code”, you get what you get, and demo examples are usually ridiculously simplified.
Write Forth. With every repetition, every IF..ELSE clause there is a stack accident waiting to happen. That'll learn you to write well-factored code. ;-)
Use tables with function pointers. That takes the heat out of complex logic - it works as a dispatcher. As a matter of fact, my own Forth compiler is built on three tables. Adding a command is as easy as adding an entry to a table. I used the same techniques when writing a Basic interpreter in Forth and recently I could take out the entire GC module and replace it with a new one as easily as changing an engine. Just bolt the thing to the chassis, hook it up to the transmission and you're done. Worked first time.
Really good video, thank you. I’m looking forward to watch more content from you.
Thanks
Thanks for the tips / information. I have mixed feelings about the topic. I want to share my point of view, maybe that helps someone thinking like me:
I hardly find bad code that is well documented/commented.
Either it's good and documented or bad and not documented (bad in terms of long functions, names like x,y,z and repeated stuff).
Even the one you show isn't commented.
Also, in most libraries/frameworks, all members are commented/documented (annotations) (like in C# the XML-comments).
They really help when trying to use the API/system, and most languages ask/want you to do it like them - so are those excluded for your advice?
I think comments/documenting should concentrate on API and everything that others can see and need to see, but not on implementation details (like lines of codes).
Important is that the information is never ONLY in the comments, but repeating the info should not be bad.
Since they are just comments, you can easily remove/ignore them later.
For me personally, I like to comment, it's fun and it helps me to code and to read later (especially in scripting and "main functions").
I also disagree that just reading the prototype of "displayPercentage(...)" is more obvious than the comment saying "Displays the the specified percentage 'p' of the supplied value 'v'."
The name of the function isn't clear enough. For me, if you want to do this, you have to go full way (displayPercentageOfSuppliedValueV(...)).
But that hardly happens, at least in my experience.
Lastly, the thing I don't get is why everyone who wants to code suddenly wants to develop instead?
"Our job as programmers is to solve problems, not to write code"
But when you begin coding or ask yourself why you started coding, I think many will tell you that they just like to write code - and not thinking about refactoring and naming things to become a system.
I don't think that we can ignore why it's called "coding" in the first place and not "problem solving".
I have to disagree on the last point you make. I don't think I have ever met anyone who's said "I like coding" and meant that they just like pushing keys on a keyboard. Much the same way someone who says "I like woodworking" doesn't mean they like using a saw to chip random blocks of wood off a trunk. Coding, by necessity, implies some degree of thought about the quality of what you are typing.
This felt a little like reading our checkstyle and pmd configuration which we use in our Java projects. Unfortunately, we do not have similar comprehensive check tools for C and Fortran, but in case someone knows some tool, let me know. One other point: Usually, when I inherit code from others, I start reading it and in the process I usually refactor it. The only thing I am not doing extensively is TDD which is impossible when you inherit code from others, but also in my own work. However, I will improve in that area ;-)
Lint will take you most of the way toward "Checkstyle for C" en.wikipedia.org/wiki/Lint_(software)
The best channel, for development - I recommend the book "Clean code" it is really nice for targeting the problems listed in this video.
You can find the book online in pdf version.
Yes, its a good book, here is a link amzn.to/3aLXGad
I agree with everything except the max 20 lines per function. I develop a web system in php and I try to follow the tips in this video, since I started developing more than 20 years ago as a teenager. But: In the system I currently develop, there are functions of hundreds of lines of code, that functionally belong together, without repeating patterns (if there were, I would have them extracted into functions by now). Splitting these functions up, would just cause dozens of parameters on every function, as the code is so interconnected. In general, these are functions, that create part of the output page of the web system, but also data analysis or data restructure algorithms can get very lengthy.
Well, if a method needs many parameters, make it a class. 20 lines of code for a method is still too long if you're talking about clean code. Saying that splitting the code into functions would cause too many parameters is nonsense. Just apply the "extract method" refactoring technique.
@@Edouardkick believe me, if you knew the code I am working with, you would agree with me, that what you are saying simply isn't applicable to the code. There is no way to make it 20 lines or fewer without ripping apart code that functionally belongs together.
We are not talking about low level functions or algorithms. Those, I agree, can be quite short without issues. I am talking about code that is processing thousands, if not millions of lines of data into a readable format in a web browser. That includes charts, diagrams, tables and so on, all of which need at minimum 20-30 lines of configuration before they are even displayed. And yes, that does include putting the settings into classes, but that still requires lines of code!
Thank you very much, Dave, for sharing your knowledge and for the awesome content of your channel. You make your points in a very light and comprehensive way, and put our minds to work along your argumentation. Very well explained and reasoned. Once again, thank you and keep up the excellent work, I'm looking forward to more content. Best regards, from all across the Atlantic ocean!
Cool, just found your channel, well and short explanation, Thank you. BTW, subscribed.
Awesome, thank you!
Great advice, but there's one thing missing. How to talk your boss into accepting the time usage of building half-decent code instead of quick and dirty solutions with endless klocs of repeating crap that becomes an incomprehensible mess about three days from when it was finalized?
Particularly if your boss "use to" do "some programming", it really can be a PITA to get a reasonable time allotment to get the job done right. Sure, it will save problems "in the future", but who knows when that future will be? Who knows who is going to be the boss responsible at that time?
In a perfect world: Explain them how cost of change goes up if code is not maintained/clean. That productivy will go down and therefore their costs for new features goes up.
In reality it will be easier to just increase your estimates on your tasks and use the extra time budget to do refactoring.
6:03 Refatoring.
Yes, sir! Now, where did I put my potato chips again? 😁
😎
Hi, I love your video, you helped me and my team improve our velocity a lot, thank you. I found myself to partly disagree about long functions, I do agree that long functions the vast majority of time are code smell and are long with no reason (probably because of duplication and not following CRP)
But there is no one length that I find functions to be "bad" from, and I will always prefer reading code vertically than horizontally.
In some application, its just make sense to have a "flow" function, one that is just doing stuff sequencially in one after the other, in my experience those function never reach 200+ lines without code smell. But I finds the practice of extracting to one time (private) functions that do not hold any domain by themselves make the code even harder to read. In one function at least the order of read is similar to the order of execution. Some people suggests to implement some design patterns like fluent code but I find it not worth it to use an abstraction for one time use as I tend to build abstraction only when I fine that I need them ( probably if a code became a repeating patttern )
Suggestion:
1. Extract to 30 lines of code or less.
2. Name the functions verb_adjective_noun() so that it is easy to read.
I like to only have one function per file, with the name the file the same as the function.
Each directory is a separate namespace. In the directory, you can see the code "folded".
3. Make one function that calls the other functions in the correct sequence.
Great video! Thanks!!!
I only comment:
* functions/types I defined, if the name is not obvious (or if I use them to generate documentation, also the obvious ones)
* difficult segments, mostly math, which I often forget myself
* things that seem like some mistake, but actually have to be this way ("don't remove this assignment. It does not just redefine an existing variable, but accessing the original variable implicitly invokes a non-performant calculation")
Not sure if a similar comment was already made to this video about code-quality, but here goes:
When writing code, always keep this in mind:
Code is written to be read by *humans*! Not by computers!
Compilers throw away the code you've written and produce binary garble to be consumed by computers.
If code were just for computers, we would still write all code in binary or punch cards :)
I agree on 4 of the ways to improve code, but not on the long methods.
I see much code with many small functions where I have to jump around from the code in one function to the other in attempts to try to understand what those functions do. It would be much faster if I had the code inline. I prefer to have one long function in that case. With blocks of code preceded by some comment adding info about what the purpose is, maybe in more words than a function name.
I prefer to look at it in terms of structure than lines of code. It does sometimes happen that you really do just have a simple, uniform sequence of many steps... no loops, no conditionals, etc, and in these very occasional cases, sure, I'd agree that leaving it all in one function would be most appropriate. But once you start to get multiple loops and / or multiple conditionals, then no, these need to be split into multiple functions. In most cases a section of code with its own conditional and loop is typically something that should be pulled out and identified as its own clearly defined function. Having multiple such sections of code aggregated into a single 'big' function runs the risk of the 'global' variable problem - i.e. what should be local variables, effectively become global, because everything is all in the same local scope. Variables you define for the first part of your long function will still be in scope for the next sections, which isn't good practice, etc. More generally, long functions that haven't been broken into smaller functions is usually a sign of an inexperienced programmer who hasn't yet fully grasped the need for, and challenge, of properly architecting software. If you have multiple loops and conditionals that you feel you need to have all grouped together in a single large function that you feel doesn't naturally break down into smaller natural functions (and most likely classes as well) of their own, then you probably haven't fully understood the problem that you're trying to solve.
About refactoring: I do not think about "refactoring" as a separately identifiable knowledge to be learned. You learn what good code is. You learn what bad code is. You learn what isomorphic transformation is. Now you now everything. If you find a bad code, you turn it into a good one. The refactoring step in TTD is not different in any way.
Mostly I agree, refactoring isn't, or shouldn't be, a separate thing. But I meet a lot of programmers that don't think about it and are scared to change code. Sure, that usually means that they don't have enough tests, but also there are lots of changes that I comfortable making, in confidence that I won't break anything making them. So learning some of the small steps, the techniques, of refactoring from something like Martin Fowler's book (amzn.to/30ntgaK) is a good idea.
@notinlist I respectfully disagree that refactoring is not a separate thing, there is inherent complexity and craft in choices made for stepwise refactoring to minimize effort and risk, especially when tackling code that requires more work or crosses current test boundaries... Knowing what you dislike currently and the end state you'd like to get to does not come close to covering this optimally, imho. In my experience as a pair, many people who are not yet well practised in refactoring struggle at times, to the extent of failing slowly and requiring reverts on early attempts.
I regret that I have but one thumbs up to give to this video.
Thanks Jim 😁
1. Your code will never be better than the data model on which it is based.
2. Well-written code tells the reader what the code does, but cannot tell the reader what the code is supposed to be doing. Comments are required to supply this information.
3. Let each function perform one task.
4. Let each task be performed by one function.
Extra function calls used to slow down code when taken to an extreme, but we're no longer in the early 1980s.
duplicated code: i follow the rule that every idea must be "symbolically accessible". meaning non-trivial things have to be a function or a class.
I have to admit that the first time I jeard some advices for code I did not u derstand the reasoning behind some of them until it was obvious while practicing.
For exampke, the 22 parameter function, an advice would be to wrap them in an object, at first this sounded like extra code to me, but now generally the objects that hold those parameters are already there to be used
My comments are documentation. I have a memory issue (like damaged RAM chips under my skull), so unless I document my code it's not very useful to me. Documented code provides code completions and popup descriptions that allows me to use the module in real projects without depending on my broken memory. The documentation of each module contains what is it for and how to use it. I know it can be reverse engineered by just analyzing the code, it's self-explaining, however it takes too much time. Code completions and popups in VS are way faster. Sometimes during writing the documentation I realize that something is wrong about in my interface or whole design and I change the code to be more usable from the interface side.
Yep. And no matter how easy it is to follow the code, the code doesn't tell you WHY you did it that way. I have code with comments like this: _//I know this looks silly and redundant but it's necessary to avoid a memory leak in the constructor of class z in the xyz library_
@@oldcountryman2795 I agree. That's the exception that comments other than documentation are useful. I sometimes add something like FIXME or TODO or HACK tags to revisit the code later and fix the thing so it wouldn't need comments. Usually the cause for weird things in the code is something else (like a library, OS behavior) buggy, when it get fixed you can remove the workaround if you have it documented.
5:00 There is one excuse for long functions/methods that appeared in both in my academic and professional life. That is the core rendering loop. The thing that really determines every pixel.
That's not to say that a sprite should be in the same location as the collision detection. Just that very few languages are expressive enough to write small rendering loops.
There were red flags in both cases though. 1. It was really hard to balance where new code should live. 2. Often the loop became "god code", something that should not be modified, especially by the uninitiated. 3. It was very difficult to follow the mutable state through even just one iteration of the loop.
a) Code comments in "repeation" style may bore out the reader & distract from important & problematic parts, thus better keep the Dont Repeat Yourself-Principle.
b) Code comments in "teaching style" may help yourself & colleages in unfrequent changed/reviewed code base e.g. already finished/delievered customer projects or stable systems core.
c) Code comments can be reduced if they reference to external description (documents/database entries): requirements, specifications, design, implementation (doxygen), issue tracking, FAQ, readme, installation, testing. That way the context can be given w/o much duplicate code comment copies, a good searchable intranet/content management system helps finding external information.
d) Code comments may be deleted if they refer to changes -> shifted them to well disciplined VCS checkin/commit/submit commenting.
I'm using C++ for my project for a bunch of reasons that I won't bore you with. I'd like to write short functions, and I'd like to refactor into smaller functions, but it's just so bugsome to have to write a declaration in a header file for every single little function. And I hate having headers that are chalk full of all these little tiny functions. I just want the header to show the top level functions. All the little private functions that the top level functions call should not be in the header file. They're just clutter at the header level. But C++ won't let me program that way. I have to create header declarations for all those little private functions.
I thought I had seen some real turds before but a function with 623 lines of code? 22 arguments? 300+lines of code inside an if? Holy shit.
Great video and channel!
Interesting, I try to do most of the stuff you mention but I need to try harder.
Re tdd: I got into programming mainly writing stuff for academic research,
no time there for writing test code as the purpose of the sw changes every day.
To this day I only do integrated testing but try to test everything in the codebase through a range of integrated tests.
But the whole reason for tests is precisely to protect yourself from breaking things when "the sw changes every day".
@@LPFan33 Not if you your code is well organised.
When I make changes I know exactly what final ouput they can influence,. Side effects happen sometimes if the code change affects processes at the same level as those for the target for improvement.
So I test related output at that level (integrated tests if you like).
The number of outputs that could be affected by a change should be very small:
POV: You are new to programming and somehow got an internship, but the Senior developer is onto you.
The senior developer is not onto you. He might have issues with your code, which is not unexpected, if this is your first position as a professional software developer. Even if you're very talented, learned a lot in school and started to program early in life and have hence some practice, there are some experiences you are unlikely to have made if you haven't maintained code over an extended period in a team.
Try to engage that senior developer, ask him what exactly is wrong and why and how to improve the code. Try to learn the most you can, that's what the internship is about.
@@guntherthomsen3864 I thought it was a good meme
I always say that rule #0 of a clean code development is: "make the life of the fellow developer easier". All the others are derived from this. Rule #0.5 is "be consistent". If, at some moment somebody else (not you, of course!) did a sh*t and you don't have the time to fix it, then either use his sh*t or create your own similar sh*t AND create a new working item for future: "fix the sh*t".
When it comes to comments is easier: if, in the middle of a method you feel the need to put a comment to explain what are you trying to do, don't put the comment! Extract a method instead.
7:40 question about "Cyclomatic Complexity"; if I have an If condition that reads like
if(Thing1 == null) return;
is this alternative more readable?
if(Thing1IsEmpty) return;
Or am i overengineering at this point?
I follow most of the things talked about in here except long code in a single function. If I don't have duplicate code, I don't make a new function. But still I follow the rule that a function should do a single thing. Sometime that single thing requires lots of stuffs. Like suppose I have to bind 10-15 different class binds to render a single thing. I can make a huge complex system to make the binding process shorter. But that breaks the keep it simple stupid, rule. Also sometimes it impacts performance. I would rather make a huge messy pointer arithmetic, template meta programming filled code, if that is more efficient than short clean code. Also sometimes to make some code shorter you need to write a function with 10+ arguments. Like supposing populating a struct with 10 different members. I would rather do that manually.
Refatoring! 😂 Thank you Dave, for that small bit of amusement.
2:00, I disagree, because nowadays every command does many things. For instance, if you are searching something in an array, you can put a comment not the kind of "finding something", but for why are you searching that - not technically, but semantically. 2:30, here, I would write a comment about what is 'r', and why it's calculated like that. And I would do that at the right of the line, to avoid growing it downward. 3:45, I think it's not always possible: sometimes it's too intricate, and you will want to break it in parts, even harder to explain.
4:25, a majority of my f()s can be seen entirely in 1 screen. However (6:03), there are some of them that take 3 or more. And their content works as something private, that should not make sense to be exposed to the rest of the project, in a form of other f()s. Of course I'm not talking about reusable things (7:07), but about only 1 goal (7:55) that requires many steps, many initializations, many private and temporary data.
Is having like 6 to 8 parameters in a constructor of an "entity" (class representing a database table) is bad ? Considering that these fields have "not null" constraint. That is the only case where i think it's OK to do so.
Sometimes, what you are passing to your method or function as parameters are really properties of a class you have not yet defined. Long parameter (or argument) lists might be cleaned up by creating classes with those parameters as properties. This puts those properties into a more reasonable context where you can control the state of the object using rules and prove those rules by TDD + BDD.
The other solution (of course) is based on the "code smell" that the function or method has a poor "separation of concerns". What is really needed are separate functions or methods, each with their own goal or purpose, and then just the arguments (or parameters) needed to get that job done. The calling code can then decide which methods or functions to call based on its needs as a Client of the others.
You might find that the answer to large parameter lists is also a combination of both of the points above-that is-you are missing some class or classes, where the parameters can be properties of them-AND-you have poor separation of concerns as well.
One thing that usually happens is that the receiving method or function is far too long (as Dave points out in this video). Therefore, a long method or function ought to be a clear sign that a refactor needs to be done, where new classes and smaller methods and functions will be the result, which will (in turn) reduce the number of method or function arguments being passed around-or at least carve them up and send them to their appropriate handlers!
@@LarryRix Thank you for your time and answer.
@@sylvereleipertz955 you are welcome! :-) Dave's video is quite compelling and full of great viewpoints.
2:32 oh thanks, now I crave orange juice.
From the book, Clean Code: "comments are only needed when we are unable to express ourselves through code"
And now we have badly written code with no comments at all, thanks Bob!
If OOP, before you refactor into small functions look to see if you can refactor out a new class. Could be that you're trying to do too much in one unit (separation of concerns).
A few times now that I've unrefactored functions so that I could extract a new class. That maintaining a connection problem seems a prime candidate.
600 lines in a class seems too large nevermind in a method.
BTW, you refactored the "c" out of the word.
If you want good code, give your engineers time to _think_. Do _not_ expect them to sit there and write pages of code. It will almost certainly be sub-optimal and should be thrown away. Often the first draft is nothing more than exploring the problem domain and determining the correct approach. Let them sit and think and experiment. It looks like unproductive time from a PHB viewpoint, but it is very productive in the long run.
💯 I say the same thing in this video: ua-cam.com/video/5g3dK2DgW-k/v-deo.html
I believe function helps to express the intent for the block of statements than acting as reusable component. Reusability is a byproduct of a function, not necessarily a goal.
Yes, that is a good description. I agree with you that using functions helps us to express the meaning of our code much more clearly.
One can't live like this in some cultures and codebases. If you are in such place: time to go forward - don't learn to tolerate code that you can't change and hate to work with.
Great as usual
Thanks for the video =)
this video was really amazing
Thanks
Do you fail the build at the commit stage or acceptance stage in the pipeline when running static analysis? I would think it's too slow for the commit stage?
I prefer to do it in the commit stage if I can, so finding tools that can give me that answer fast enough. In Java Checkstyle and Findbugs are a decent start, Lint and Lint-like things are also good. Also, turn up the warning level of your compiler to max, and fail commit if you get a warning.
It's so much fruitful, thank you so much then
Thank you
I find those images of code very difficult to read, they're so small. I'll take your word for what they say, but you could have illustrated the same ideas with cartoon blocks rather that actual eye-straining text. Or you could sacrifice the constant presence of a human figure taking up half the frame.
Very nice video
I sometimes prefer longer methods over (too) many short ones. In my opinion it's often easier to understand and find bugs then in many short ones. But I agree that 623 is too long. But I would also say that 20 lines is a very low threshold. I would probably have it around 50 lines. But that's just my opinion.
For me 20 lines is usually too long. I find most functions work well with 7 lines of code (counting lines that contain alphanumeric characters; brackets don't count). I'm not sure what you mean by finding bugs? Can you explain? I find that with 7 lines of code per function - with each line properly commented - bugs don't have anywhere to hide in the first place. Bugs are something I vaguely remember of the past of 20+ yrs ago.
I really liked CI giving error on code smells, damn I never thought of that, was always looking for better code review tools instead 😁
There are tools that can be applied on local build and will prevent code smells even leaving your workstation. We should catch those ASAP
tell me some
I am only aware of basic lining of ecmascript, typescript.
Need more control, like functions line of code limit.
any place to refer?
got it - eslint.org/docs/rules/max-lines-per-function
I think that adding it to CI is a good step.
@@vaibhavarora7782 Yes Lint can be used for JS/TS I guess. For backend there are solutions like Detekt for Kotlin. Probably for many languages, there is something helpful.
Sometimes I feel sorry that no one is willing to pay the extra penny on refactoring. Although this video is so true about refactoring but unrealistic in some situations where you not only inherited bad code, but strict deadlines that leaves you without having the chance to clean the mess.
I confess that I don't really buy-in to the "no time to clean up" idea. I don't think that we should ask permission, I always tidy the code in the area that I am working. Of course you may not have the time, or freedom, to do large-scale changes, but many small, often simple, refactorings can quickly add up to a better codebase.
@@ContinuousDelivery still can't see how would I have time to refactor 300+ lines of code if the job is to change one line of code where it was originally estimated for 1-2 hours. Now I am in the middle between theory and reality.
@@AlaaAlMaliki IMO your job isn't to "change one line of code", ever, it is to work in a sustainable way.
Also, don't necessarily change 300+ lines in one sitting, change a few lines in the area of the code that you are working on to make your work clearer, more expresive and better designed. If that requires you to change 300 lines, then maybe your code is very bad and if you change the 300 lines now, you will be going MUCH faster next time you touch that code.
@@ContinuousDelivery Thanks for that really helpful, I am trying not to miss any of your vids
The concept of a deadline is inherently stupid anyway. It's not done until it is done. At best, you can forecast when you expect something to be done. At worst, someone above you in your organization gives you a deadline, increasing pressure on you. Pressure that can lead to lower quality code, possibly even introducing mistakes, on top of increased stress levels which can lead to all sorts of health and behavioral problems.
Awesome ! Thanks sharing!
Thanks for watching!
11:30 "Adopt the discipline of allowing yourself one conditional per function or method." I'm assuming this means 1 if statement.
What?! I don't think any of my code could meet this requirement. There are too many places where I need very short if statements looking for error conditions to fix or throw on.
I think that constraint might be a bit too extreme. However, one way to make it work would be to distribute error checking to were it's really needed. If you have
I took that as: limit yourself to one level deep, not necessarily one condition per function. I dont agree with either notion, but the bulk of this video seemed to be reasonable advice, especially on comments!
I have seen a function with 11,000 lines. Several levels of if and switch...
But, honestly, also me, 20 years ago: "why should I want to write header files, when I can put everything in one single c-file?"
And: "every line of code needs to be commented."
How things (and comprehension) have changed by 180° in the meantime...
1. Try to avoid writing a new code
2. Do not use else in any method. At least try to avoid it.
3. Each method should have only one flow.
Do you apply the limit of n. of parameters also to constructors?
Yes, I try to.
If you need very complex initialization then a factory pattern is for you. If nothing can be automated about the initialization of 200 parameters, then you know that you are already in hell and you might as well ask Satan for a new assignment in the glowing ember pit. :-)
200 parameters?! That's crazy. The max. I've ever seen a function have as parameters would be 15~20. And even this is troublesome.
@@Sergio_Loureiro That was my point. There is a level of complexity, even in initialization, that requires automation. Not sure I have ever seen 200 in my life, either, but I think I have seen something on the order of 50 or 60 in a plot function once. Somebody tried to cram everything and a kitchen sink into that poor function call.
It is not all that hard to get to impractical numbers of parameters. Look at GUI elements like buttons, for instance. Location, size, colors for background, borders, highlights, style, fonts etc. It adds up quickly and personally I am becoming frustrated if I have to deal with even a dozen parameters.
Fantastic
Was expecting a fake out with the second commenting example where he made you look at the file header comment.
😉
At last, you can also some good and better code for better understanding of your video
TDD has never worked anywhere I’ve ever seen it implemented 😞
I have a similar opinion but writing unit test cases have saved my bacon time and over.
@@MrXperx I like unit tests and I like integration tests. I’ve just never seen TDD work in the real world.
@@MiningForPies What are the issues that you run into?
@@CynicalOldDwarf it’s not flexible enough. If you don’t do some design work upfront you end up throwing away tests, constantly changing them and in larger terms it becomes a nightmare to manage. Worked with guys who would kick off if you started with a class rather than a method (because no test had been written that meant a class was needed) some of the most dogmatic and terrible developers I’ve ever worked with,
comments: i don't write them unless i think the reader will need information that's not in the code
function size: no limit here. i write code in scala which allows nested functions. a function can have 1000 lines but is structured very well
This guy remind me of the with from the Curious Droid channel, but for programming :D
Magic numbers instead of enumeration/macros.
If(variable ==1 || otherVariable == 5)
Impeccable!!
pfff, 623 line function, I had to debug a vb (I know, I know) library, it had 3 functions each of which had 40 params and over 1000 lines; It was essentially the same code in each with a few minor differences too.
After refactoring I got it down to 500 lines total in the library in multiple small functions. ;)
I love the smell of deleted code in the morning 🤣
I had a massive laugh about refatoring
Improving your code in this way heavily depends on TDD and CI. You will not have the confidence nor the motivation to change your code if you can break it without knowing it. For example, if you rely on a tester to click on your web page then your code is doomed. What, you think the tester will test everything again just because you want to refactor? And you think you will not break your code when refactoring? Cut it out! That's why Martin Fowler said in his book you must test all your code before you consider refactoring.
You misspelled refactoring at 6:15
The old ones are the best: KISS
I think everyone will agree with that, but few people practice it, although most probably believe they do.