Tap to unmute

ITT 2016 - Kevlin Henney - Seven Ineffective Coding Habits of Many Programmers


Пікірлер • 611

  • ZoidbergForPresident
    ZoidbergForPresident 4 жыл бұрын +437

    Here are the timecodes!
    Noisy Code 2:55
    Unsustainable Spacing 10:44
    Lego Naming 23:15
    Underabstraction 31:25
    Unencapsulated State 34:59
    Getters and Setters 39:11
    Uncohesive Tests 42:01

    • SatumangoTheGreat
      SatumangoTheGreat  Жыл бұрын +4

      You forgot about the ninja at 43:32

    • Szalay István
      Szalay István 2 жыл бұрын

      10:37 Mind the Gap (Scooter album)

    • MacMikeG
      MacMikeG 4 жыл бұрын +11

      Let's eat grandma! 7:50

  • Les Pinter
    Les Pinter 4 жыл бұрын +7

    I've almost come to blows with arrogant programmers (one in particular, who complicated life for thousands of his customers) who insisted on the correctness of each of these. But this is the first time I've understood why I thought they were wrong. Thanks!

  • JoeriVDE
    JoeriVDE 3 жыл бұрын +7

    16:48 that is so true. I freaking hate that mentality. It's also a very common problem that's not only applicable to programming. If you write something that has the goal of being read and/or used by others, make sure they understand what you're trying to explain/accomplish with as little effort as possible. Thank you.

  • Jesse Potter
    Jesse Potter 5 жыл бұрын +9

    Great lecture! Had me laughing out loud at times, and definitely changed my perspective on writing code. Thanks :D

  • Lawrence Miller
    Lawrence Miller 2 жыл бұрын +5

    Minute 34:00 Code in the language of the domain.
    For example, use the hardware I/O signal names which are on the schematics in the code as constants or field names. Some people rename things unnecessarily making the connections harder to find.
    For example, code the mathematical formulas the same way users write their formulas, unless optimization is required. Use the same numerical units as the user in the code, again, unless optimization is required.

  • Michael Goss
    Michael Goss 3 жыл бұрын +12

    Many years ago while working with another team member to fix some broken code written by a dev who was let go, we ran across a try/catch block that ate an important error with a comment that said "Paula doesn't like this error". Holy hell.

  • babgab
    babgab 2 жыл бұрын +5

    Some of the points on indentation could be alleviated by mandating that everyone run an autoformatter before checking in... But that only works on teams that use a style that is amenable to autoformatting and even if they do, on legacy codebases it can be counterproductive to use autoformatters. :|

  • Rasmus Loqvist
    Rasmus Loqvist 5 жыл бұрын +25

    I kinda disagree on the exceptions. When reading through code a lot,
    you get used to seeing certain words, like "Exception".
    Then, when I have to form an impression about it,
    I see the word "Exception" in a class name somewhere,
    and I immediately get a quick and shallow perception of
    what it is doing;
    "This is an exception, here it winds up when something
    goes wrong. If I need to know exactly what went wrong,
    I can at any point read the full name of that class."
    I do not need to know or analyze the name "EntryPointNotFound"
    if I quickly see "Exception" as part of that word. It is four words
    I would have to put together in a sentence in my mind
    and make sense of it all, before I realize that it is an exception.
    All in all, great talk. Loved it!

    • Alexios
      Alexios  Жыл бұрын

      If your code base is growing I think suffixes will be better. I prefer to set nice names for Domains, business logic and don't think about a nice name for Exception (I mean nice - without suffix).

    • John Irwin
      John Irwin 3 жыл бұрын +2

      The real reason most frameworks of any appreciable size (like .NET) use conventions like this is that they will often have several types related to the same concept, e.g. XyzException, XyzDescriptor, XyzEvent and in this context to not use a convention like consistent suffixes is, well to use Mr. Henney's words, unsustainable.

    • Crotchy
      Crotchy 3 жыл бұрын +3

      I prefer to have Exception as suffix to class name because it's easy for developers to discover at a glance which classes are exceptions when looking at a list of class names. It can save time.

    • Severity One
      Severity One 4 жыл бұрын +1

      Yes, it's established, but it's also useless. java.lang.IllegalArgumentException could easily do without the "Exception" and still be crystal-clear. Yes, you can instantiate an exception anywhere, like "Exception e = new IllegalArgumentException()", but it only really makes sense to either throw or catch an exception. This is not C++, where you can throw any kind of object or primitive, like strings or integers. There are very few exceptions in Java that become unclear when you remove the "Exception" from the name, with "NullPointerException" being the most obvious.

    • CharmedQuarkSystems
      CharmedQuarkSystems 5 жыл бұрын

      Yeh, in my code base (C++) I have a single TError class. I find that ultimately that works best, I can check if it's a specific error from a specific module (facility I call them) if desired. 99% of the time the catching code doesn't care what it is, it just wants to recover and continue, or clean up and re-throw.
      I think that the rule that exceptions should not be just a way to unwind the stack plays a part in this. I don't throw exceptions that are meant to be caught hardly ever, because that's then not an exception per se, it's a way to unwind the stack. There are some few legitimate places to do this, but not many, IMO. If you aren't throwing exceptions that are meant to be caught, then its a lot less likely anyone wants to to catch them by a specific type.
      Also, if you limit exceptions to purely exception situations, then you can use the debugger's 'stop on throw' mechanism very conveniently. Whereas if you are really using exceptions to unwind, you may be constantly hitting throws that are not really errors and so they are just annoying when debugging. If I hit a throw, it's 99.9% likely bad and something I want to stop and look at.
      Obviously you can derive all of your exceptions from a common exception class and catch via that common class. But I'm assuming that they get sliced in the catch if you do that? It's been so long since I looked at that that I don't remember.

  • superstringcheese
    superstringcheese 5 жыл бұрын +14

    Love the reaction shots of all the programmers just wishing he'd get to some point.

  • Zoran
    Zoran 6 жыл бұрын +393

    Best talk I've heard in a while.
    It really changed how I think
    about code.

    • DarkMukke
      DarkMukke 2 жыл бұрын

      @Mikko Räsänen in modern browsers you mean, and this comment is 2 years old.

    • Mikko Räsänen
      Mikko Räsänen 2 жыл бұрын

      @DarkMukke you can actually do LOT in modern CSS, before you hit the need to do JavaScript, if you should so please

    • K T
      K T 3 жыл бұрын

      Dmitriy Getman why brother?

    • Vinay Verma
      Vinay Verma 4 жыл бұрын

      this is your sarcasm right

    • Elijah Beale
      Elijah Beale 4 жыл бұрын

      Dmitriy Getman Interactive style isn't stupid. For somethings it is a very good idea. For Common Lisp style interactive (read: live) programming it is especially good to see how changes affect your program while it is running. It is also good for prototyping and exploratory programming. Common Lisp has the option of compilation, btw, which is great as it gives you the option for performant programs. However, to summarily disregarding something as stupid (and not respond meaningfully to comment. ie having intelligent discourse) means you are either a troll, or that my insight (or common sense) is just going to be wasted here. Ultimately you get to decide that.

  • Gustav Jansson
    Gustav Jansson 3 жыл бұрын +1

    Looking at the student code at kzclip.org/video/ZsHMHukIlJY/бейне.html for the RecentlyUsedList it looks like they didn't know about the [] operator or the Remove method, the rest of it more or less a different codestyle, but Kevlin for some reason also decided to change the order of the backing list, making items[0] to be the least recently used item instead of the most recently used that the student used, so he needs to do the whole items[Count - index - 1] shebang. The fixed student could would then be like Kevlins code but with Insert(0, newItem) instead of Add(newItem) and items[index] instead of his weirdness. Seems more readable to be honest.

  • moto_HYUTS
    moto_HYUTS 4 жыл бұрын +1

    One of my top concerns with coding is nomenclature and structuring. Haven't finished the vid but I think its going in a way I will like.

  • edgeeffect
    edgeeffect 3 жыл бұрын +4

    Excellent talk... it covered many things I rant about that "other programmers" do..... and many of the things I do that the other programmers rant about when I'm not around.

  • Eidetic Ex
    Eidetic Ex 5 жыл бұрын

    I've wrote a lot of code following his best practice suggestions after writing a lot following his not so best notations. Certainly understand that pain of looking at some of those junk styles when some of my code base is over a decade old.
    Really though all that matters is that you pick a style that makes sense at a glance and stick with it. Also helps to remember we're all using wide screen monitors and most of us set our text to be roughly 36 pixels wide per character (9 or 10 with Lucidas, Consolas, Source Code Pro or similar semi-mono space fonts). We have the space, don't be afraid to use it.

    • konrad303
      konrad303 3 жыл бұрын +1

      I use a wide screen to split it into a bunch of panes, so I can see different related parts of code in a project at once. No sane person would use the horizontal space a wide display offers to fill it up with long lines. Long lines are hard to parse for the reader.

    • slag02
      slag02 5 жыл бұрын

      What about when I am coding on production in vi? I joke I joke..I kid I kid...

  • ThePandafriend
    ThePandafriend 4 жыл бұрын

    I disagree on the noise one.
    Well, not completely, but for better readability it can also make sense to point out obvious things like //class variables //Getters and setters //Constructors //public methods //private methods //general notes and testcode. The last section is mostly for yourself, but it doesn't hurt to include it. It's below all other stuff anyway.
    Also in some cases additional notes can make sense. Of course you shouldn't write too much, but some notes can help with the understanding of the code and when there are more complex things can tell the colleague how your way works. He'd figure out eventually but writing something like "//implementation of imaginary numbers" he knows what the code means and don't even has to try to understand it in many cases.
    Also it can make sense to explain some algorithms because they are based on what you thought and others think differently. This one is not unique to programming though. But of course you shouldn't use this as an excuse for sloppy code that's hard to read.
    Referring to getters and setters I always use what I need. Sometimes I need just a getter, sometimes both, sometimes just a setter and for many fields neither a getter, nor a setter. I thought that this is common practice.
    And why should I remove the word "get" or "set"? Sure, it has tons of meanings but in this case everyone knows what get and set means.
    Overall a nice presentation. But it had a lot of noise ;).

  • Glenn Clark
    Glenn Clark 6 жыл бұрын +5

    One of the reasons I like using python so much is because it fosters a small number of lines as well as enforced indentation. I can read my code a lot easier when I don't have to search through page after page.

    • Nathan Smith
      Nathan Smith 5 жыл бұрын +2

      until some jokester sets your .vimrc file to interpret tabs as 8 spaces! :-O

  • Tom Corwine
    Tom Corwine 2 жыл бұрын +2

    Great talk! I don’t agree with everything, but I believe listening to and understanding the point of views (points of view?) of people with whom I disagree is just as important as listening to people with whom I agree. It’s the only way to open one’s self to new ideas. This talk has changed my views on several habits-I’m free to consume or discard whatever I believe to be valuable or invaluable.
    I don’t think he was saying, ”do away with comments”. I think he was saying don’t use comments to point out the obvious where your code should communicate on its own. Any developer knows comments are necessary to explain why something is being done, or what is being done if it just isn’t obvious. It happens. Sometimes I will write something that just isn’t clear to a passerby-I want them to understand what I am trying to do. Maybe they can write it a better way, and they can suggest a better solution.
    If anyone uses iOS beta versions, it’s also necessary to comment all the work-arounds for framework bugs :)

    • Tom Corwine
      Tom Corwine 2 жыл бұрын

      Ugh. My new line whitespace between paragraphs wasn’t preserved when posting my comment above.

  • Cathmeister
    Cathmeister 2 жыл бұрын

    Comments are very useful when using DLLs. Is a user supposed to find out if the encapsulated list doesn't allow null values or duplicates via trial and error? When I'm using third party code, it is definitely easier if they over comment instead of under comment. What is obvious to the coder is not always obvious to the one reading the code.

  • Georgy Padalko
    Georgy Padalko 4 жыл бұрын +16

    Quick tip: always KEEP SLIDES ON SCREEN please! There's a reason a lecturer keep them visible, we need to be looking at them while listening to him.
    Unity-talks is a great example: slides full screen + small picture of a lecturer in a corner.

  • triularity
    triularity 4 жыл бұрын +3

    I agree with most of the ideas given (and have been applying them for decades). I had issues with a few of them.. some because the example was weak (even if the principle was valid, sometimes).. or they don't make sense in certain languages/contexts (e.g. how do you have a member variable named foo and a getter named foo, which returns variable foo's value? Even if the language allows it without collision, it would be very confusing).

    • Alonso B
      Alonso B 11 ай бұрын

      i realize this is an old comment but perhaps other readers may appreciate this
      in c# a convention is to have the private variable start with underscore, and the property capitalized without underscore
      like this:
      private int _foo;
      public int Foo
      return _foo;

  • SmartK8
    SmartK8 4 жыл бұрын

    I just forced all the colleagues with a gun to their head to use a common formatting engine. "Don't cry and beg for your life", I've said, "it will be better for all of you.. trust me". I'm glad I could share this story with you. We only got one day of Internet allowed here in a hospital for the criminally insane. They still use this common formatting engine at my prior workplace. They send me postcard with thanks every year.

  • Paresh B. Patel
    Paresh B. Patel 2 жыл бұрын

    Thank you ever so much for an engaging, illuminating and beautifully delivered talk, Kevlin.

  • Tony Gustafsson
    Tony Gustafsson 4 жыл бұрын

    Fantastic speech, really! :)
    I don't make many comments now days... my colleagues are on the same level as me, so as long as I name my functions and variables logically I see no reason for it. I can comment things like ajax requests and what I expect back or regexes maybe.

  • Clay Kellogg
    Clay Kellogg 4 жыл бұрын +5

    I've seen several presentations about coding habits. This is by far the best.

  • Rob Uttley
    Rob Uttley 4 жыл бұрын

    I liked some of the little quips and jokes. Interesting talk. Over-the-top complex naming and visual layout of code are important ideas that don't get discussed often enough.

  • TheRedScourge
    TheRedScourge 3 жыл бұрын +2

    Cool, I guess I independently discovered this and fixed it in my code years ago. Good to know I'm not the only one noticing this problem.

  • Linux Gaming in FullHD 60FPS
    Linux Gaming in FullHD 60FPS 4 жыл бұрын +1

    Evolution of code finds its way. If it's to difficult to maintain it just gets abandoned and the software gets written from scratch. The process repeats over and over again. Some people see the absurdity and waste of resources in this as we just "reinvent the wheel"... This is what usually happens to open source projects. And that's why there are many wheels that do almost the same thing and not enough resources to maintain them.

  • Bryan Chance
    Bryan Chance 3 жыл бұрын

    I've seen production code (from a "Senior PHP Developer") that looks like the examples given here, including tests that just test individual methods. LOL. Another great talk. I learn so much from watching these videos. Thank you.

  • Chyhao Sun
    Chyhao Sun 4 жыл бұрын

    在英语中释义最多的单词前三里,get 和 set 这两个词占据了两个位置,把 get 的释义全部列出来的话,可以占据35页的空间。很多开发者在代码中大量使用这两个词,觉得这像是英语的惯例,而且两个看似互为反义的两个词用起来很和谐……并不,从语言学的方面来讲,set 的反义词是 reset 或是 unset。不过在某些条件下,人们让他们的 IDE 自动把 getter 或是 setter 整合在代码里,这听上去很棒,错误的事情被迅速完成了,而人类还能对此避重就轻。大部分情况下,我们的对象内需要一个 getter 但并不需要一个 setter,此外我们应该摆脱这两个单词,因为在英语中「get something」通常会产生一些深远的副影响。

  • Undisputed The Ophidian [TM] world champion

    Thanks for sharing. T-SQL, or general SQL code formatting best practices would be appreciated.

  • 8BitXatu
    8BitXatu 4 жыл бұрын +7

    THANK you for mentioning argument lists, I was always dissatisfied with lining the arguments up on the right

  • Dustin Rodriguez
    Dustin Rodriguez 5 жыл бұрын +2

    This tempts me to wonder whether it would be possible to actually derive a measure of 'signal to noise ratio' or 'cognitive load' for a body of code. It might take some experimentation, but I imagine it would be possible. I'd start with figuring out what other information is necessary to comprehend a given code file. Things like how many references to code defined in different places there are. If it uses 10 custom data types defined elsewhere, that's 10 references. Then weight that by the SnR of those declarations. So if your code, to be understood fully, requires consulting a great many other sources which likewise require consulting a great many other sources and so on before you actually get to enough 'meat' to comprehend the actual substance of exactly what the code is doing and how it is doing it, the score would be very low.
    Integrate that measure into an Eclipse plugin or something and see how peoples code changes when they've got a plugin evaluating it and telling them their code is 'substantial' or 'deplorable'. A dreadful amount of Java code in particular would receive cataclysmically bad scores, requiring you to venture through half a dozen large complex frameworks, hopping through a dozen levels of abstraction, understanding dozens of custom data types that provide almost nothing of substance just to grasp how a very simple operation is performed.

    • Ethrel
      Ethrel 5 жыл бұрын

      Except that 'number of references' is potentially a poor indicator. Just because I define my own class to handle something doesn't mean you need to understand the internals of that type -- if that type is clearly named and the properties, methods, etc. are as well. If I look at a code file and see a reference to some custom data type, but everything is properly named (And not overly-abstract), I can easily understand what is happening in the code I'm specifically interested in without needing to go look up the referenced type.
      If I, for example, see a class named Inventory in code that handles item movement in a game, I can easily picture what that Inventory class does (stores items, allows addition and removal of items, etc.), and don't really need to understand how it works internally. Especially if the methods are well-named and intuitive as well.
      Unfortunately, I have no more constructive ideas on what *could* be good metrics of SNR that could also be picked up by a program/plugin. The examples used in the talk have nothing to do with references and custom types. It's all about needlessly verbose code that could be shorter, with less logic.

  • impero101
    impero101 4 жыл бұрын

    On the topic of structuring his unit tests, how would it look when testing methods of a class? Any examples where he talks more in depth of this way of structuring it? I've always just stuck to the MethodName_TestingState_ExpectedBehavior but I can see where it is lacking.

  • Findecanor
    Findecanor 4 жыл бұрын

    Everyone should embrace _Elastic_ _Tabs_ for aligned indentation independent of symbol length.
    ... except that causes problems because not every editor that programmers on your team use support it.

    • Dan Q
      Dan Q 4 жыл бұрын +2

      ...or just use spaces which look the same in every browser and IDE.

  • Jollyprez
    Jollyprez 3 жыл бұрын +87

    Comments in code are for when you're fixing something, and only a hack will work, and you're explaining why the hack was necessary, and that you're really a good programmer, and are embarrassed by this hack, but it has to go in because time constraints. Honest.

    • jurchiks
      jurchiks 11 ай бұрын

      Well, sometimes there are things that have to go in because your boss asks you to, but they're really wrong, but it just has to be that way, so I usually just write a comment that this HAS to be this way and it is "correct" just because...

    • Randolph Aguanomwan
      Randolph Aguanomwan 2 жыл бұрын +2

      😂😂😂 I am offended because this makes so much sense

  • Stephanie Leon
    Stephanie Leon 3 жыл бұрын +2

    He has a great sense of humor - I wondered at first if we just couldn't hear the audience laughing, but I have decided all but a handful must have been asleep, which is a shame!

    • Christoph Rackwitz
      Christoph Rackwitz  Жыл бұрын

      but really, it's likely the language barrier. I see that all the time. english speaker in front of non-natives (with awful english). they look concentrated but they don't get half of it. trying to make a joke... a valiant effort

    • Christoph Rackwitz
      Christoph Rackwitz  Жыл бұрын

      perhaps there were many germans in the audience. germans know, when they laugh, they sound frighteningly sinister.

  • Flávio Sousa
    Flávio Sousa 2 жыл бұрын

    Theres some concepts he touches on that I have never heard mentioned anywhere.

  • Niko Kauppi
    Niko Kauppi 4 жыл бұрын +2

    Hmm... I pretty much agree with everything except not having a getter and setter.
    If I have an container.Size() I usually think, "Size what?", I want to be explicit and know the action that we're performing, so I'm all in for container.getSize().
    I think get and set in the context of programming have pretty refined and specific meaning, of course the people will have to know it first though.
    Of course you should only use get and set where it actually makes sense to do so.
    On another note, if it's a calculation, that can potentially take some time, and return type is a newly created value I might use a word "Calculate", for example "CalculateMatrix" on a 3D scene object.
    Some of the keywords I defined for myself over the years... Just as an example.
    "Update" for advancing simulations / managers, "Task" for multithreaded workloads, "Job" for individual workload within a "Task", "Manager" for an automated sub-system handling certain tasks, "Handle" for a managed object within a manager (usually used when destruction of the handle needs to inform some manager)...

  • Christoph Rackwitz
    Christoph Rackwitz  Жыл бұрын

    the specific value I'll derive from this talk: show it to others that expect me to *justify* what I'm doing with better articulation than "why isn't all this _obvious_ to you?"

  • Árpád Goretity
    Árpád Goretity 6 жыл бұрын +21

    Excellent point about getters and setters. Objective-C uses the "no get for the getter" naming convention for properties, by the way. Also, FINALLY someone dares to declare what is THE visually correct way of arranging longish argument lists.

    • Crotchy
      Crotchy 3 жыл бұрын

      @Netherlands031 I disagree with how he used his examples to back up his reasoning for not using "get". He's playing word games. We withdrawMoney from an ATM, not only "getMoney". We "marry" someone, not only "get Married". A word game in the English language does not necessarily prove a contradiction to what we write in a program.

    • Cees Timmerman
      Cees Timmerman 5 жыл бұрын

      Nobody is stopping you from adding #{ and #} to your Python code, which, like formatters, should not be needed, as improper indentation doesn't run in Python 3 and Python 2 with the -tt switch. Code style 101 includes indentation and consistency.

    • TheEVEInspiration
      TheEVEInspiration 5 жыл бұрын +1

      Code becomes sensitive to leading spaces, which in turn results into errors and many will be very easy to miss, so it distracts. Editor side effects, perfectly fine or even greatly desired with other languages, became a source of error.
      Disallowing the coder control over formatting in a way that conveys real meaning is bad. It makes the language unworkable to anyone that knows what he's is doing and what a good way of conveying it is.

    • Netherlands031
      Netherlands031 5 жыл бұрын +3

      'it rings language design 101 bells in my head' is not really an argument, why is indentation instead of braces bad again?

    • TheEVEInspiration
      TheEVEInspiration 5 жыл бұрын +1

      In Python indentation affects the functional meaning of the code. It is possibly the worst mistake any language writer can make, just to get rid of the also visually useful { } brackets. Its like the typical Apple design, leave out what you need often and have others try to patch things up and work around it while they brag how great they are.
      This alone makes the whole language a no-go for me as this flags all the DO NOT EVER DO, language design 101 warning bells in my head.
      Python has sadly been adopted by a very interesting and hot domain, even if it is very far from the best choice. It is similar to using PHP for writing operating systems, just a bad mismatch. But as the subject is complicated, people tend to use libraries and thus the language they are written in, so it ain't going anywhere soon.
      I got some hope left its unsuitability will allow vastly different systems to eventually bring it down hard. But going away it never will, because there is code written in it. Even today there still runs COBOL and the like and coders in that language get well paid for what essentially is a mistake. The situation has bad incentives written over it, everywhere.

  • effsixteenblock50
    effsixteenblock50 4 жыл бұрын +110

    "There is one place to put your curly brackets...." the camera stays on Kevlin, who eventually clicks to the next slide and we never see the code. Nice.

    • Pedro Amaral Couto
      Pedro Amaral Couto  Жыл бұрын

      It's below the parameters. It was shown briefly before he said that.
      Despite the bad rap about PHP, I learned to do it that way thanks to that language and PHP Mess Detector. It's much faster to count the parameters that way. You don"t have to parse entire lines of code.

    • superscatboy
      superscatboy  Жыл бұрын +3

      I caught it. And he's right... you need to put them exactly where I put them - in the correct place.

    • Eugenijus S.
      Eugenijus S. 2 жыл бұрын +12

      its at 22:55, just pause the video! :)

    • Max Okev
      Max Okev 2 жыл бұрын


    • Max Okev
      Max Okev 2 жыл бұрын +2

      Well I got it - watch again

  • Gordon Sim
    Gordon Sim  Жыл бұрын

    Great talk but I just wanted to point out few things
    29:00 I do agree that names should be simpler but exceptions should be the exceptions(haha). Exceptions are bad things and you don't want them. So you make them pop out like a sore thumb. They need to be verbose and unfriendly because people need to think twice when they see them.
    35:20 Singletons are generally ad-hoc solutions for many cases but there are some cases that singletons are the most logical solution i.e. I/O. There is generally only 1 physical disk that the program has access to and it would be more confusing if there are several classes that handles I/O.
    41:31 I prefer prepending "as" or "to" to the "hundredth" so it is clear that it is converting to something(or use a better language that supports property like C# or Kotlin) but I 100% agree that "get" is not the word.

  • Sure Lock
    Sure Lock 3 жыл бұрын +1

    22:54 My god I figured this out on my own in my first CS class, and I could never figure out why so many professionals and textbooks keep the opening curly bracket at the end of the last parameter

    • Marek Piirikivi
      Marek Piirikivi 3 жыл бұрын

      A line less is why. But I agree. It makes code (and scopes) more readable.

  • RiotGearEpsilon
    RiotGearEpsilon 3 жыл бұрын

    You put the word 'exception' in exceptions so that you can pull up a list of all the exceptions in your autocompleting IDE.

  • Cameron Martin
    Cameron Martin 4 жыл бұрын +1

    In JS, I use the following alignment for multi-argument parameter lists
    function foo(
    ) {
    // some code
    This works great with ES2017's trailing function commas.

  • rocknlouie
    rocknlouie 3 жыл бұрын +24

    I have met many programmers who think that the more complicated the code looks, the better it must be. They make even the simplest things complicated, just so when you point out how inefficient it is, they can say, "you just don't understand it."
    I have come to believe that they are more invested in making sure no one can point out the flaws in their overcomplicated mess, than they are in actually solving the problem at hand. I have wasted a lot of time sifting through their code, just so I can point out exactly why it is bad, or where it goes wrong. All they are doing, is trying to hide the fact that they don't know what they are doing, and wasting their time, and my time, by trying to cover it up with layers and layers of unnecessary bullshit.
    In Hungarian, there is a way that they mock this behavior with a gesture, where you reach over your head to scratch the opposite side of your head, instead of just using the closer hand.

    • Dax Ramdac
      Dax Ramdac 9 ай бұрын

      I dont think I've ever heard anyone, even a newbie who's only been coding several months maybe a year or so, say complicated looking code must be better.

    • Justin K
      Justin K 9 ай бұрын +1

      dunning kruger effect,
      like when people say coding is easy shortly after just starting because they know how to write a simple console app.

    • Civilized Gangster
      Civilized Gangster 10 ай бұрын +1

      "An idiot admires complexity, a genius, admires simplicity" - Terry Davis.

    • Tim Ottinger
      Tim Ottinger 3 жыл бұрын +1

      "If you don't understand it, you should learn to read better -- it's not my job to make you understand it"
      said every really ugly code-writer ever.
      Victim-blaming is easier when they're OUR victims, because we never really cared about those people anyway.

    • Johnson Deng
      Johnson Deng 3 жыл бұрын +2

      Comment is hilarious and mildly informative. You got my upvote.

  • musashi939
    musashi939 2 жыл бұрын

    Hahaha yes. That German one is gold. I mean yeah this word appears to be kinda artificial but it's really awesome that you can string words together like that instead of getting all descriptive. This of that containing another thing vs thisthatcontainingy.

  • Little Monk
    Little Monk 2 жыл бұрын

    I have one
    I was watching the MS .NET Core two "experts" giving tuition on .NET Core 2 the other day. At the end they wrote a short loop to demo their new feature. One asked the other, "Shall we use 0 or 1 to start the index in the for loop?" the other replied "I am 0 person so lets go for 0". I screamed at the monitor and said no. It is not a mater or like, there is a logical reason behind it. If you are doing a loop counting real world objects, always use 1, since anyone reading and tracing the code can instantly workout the value is the real value and they do not need to add one to convert it. And guess what, when they compiled it they go an out of bound error and they said "Oh yes we need to subtract one". I was proven there and then. It is dangerous and unintuitive.

  • Raz0r7685
    Raz0r7685 5 жыл бұрын

    I feel like this is deep wisdom that will take years to process...I am intrigued, but probably only like the novice martial artist watching a 10th-Dan master practicing a routine...

  • liteoner
    liteoner 5 жыл бұрын

    This guy is my absolute favourite

  • Ben Adelaide
    Ben Adelaide 8 ай бұрын

    For someone that believes in using words to convey meaning, I very succinctly learned he loves hearing himself talk.

  • Paul-Sebastian Manole
    Paul-Sebastian Manole Ай бұрын

    Brilliant talk!

  • Witheld Name
    Witheld Name 4 жыл бұрын

    I get that indexing can be not never clear, but ever since I switched over from Java to a non-strict OO language, it appears that getters and setters and the like are really just noise too. Take, for example, a vec3 class. Here is a bad example: pastebin.com/c4TQEh4N ... Here is a good example: pastebin.com/h7Ngnudu
    The difference between them is the getters and setters and making x y and z public rather than private. There is of no gain to make getter or setter leaf functions like this. It is only more typing or auto generation. A correct use case would be to process information in the getter or setter like seen in the magnitude function provided in each. This may leave you with the hunch of 'now I have to remember what is or isn't a function' which isn't an issue on its own, buuuut C# took a step and said, `here use these get and set and we will treat your inevitable function as a variable so you wouldn't have to be bothered` which has its ups and downs of masking what things do.
    When it comes down to having to do
    You run into 2 problems. The first is you can't plainly tell that I have an extra closed bracket. Another is you now added more words to index what you are working with. Finally, they don't always match up... what the heck is haveThing()... oh a boolean?
    I much prefer
    Especially with naming conventions for types, which helps when your popup or breadcrumbs takes 0.5-1 second to show anything useful.

  • Mathew Guest
    Mathew Guest  Жыл бұрын

    Amazing, one of my favorites

  • Channel Dad Bryon Lape
    Channel Dad Bryon Lape 5 жыл бұрын +3

    K&R solved the { question in their book when they said it was put at the end to save space for printing, but did not recommend it as a coding style.

    • Emmet Caulfield
      Emmet Caulfield 2 жыл бұрын

      An opening brace on its own line is a complete waste of vertical space, which is actually quite precious in terms of communicating information "by the screenful". If you doubt this, learn Python.

    • konrad303
      konrad303 3 жыл бұрын

      When Kevlin shows the Code replaced with only Xs to condense it to its the visual structure, the point however is that indentation matters the most. Putting the { at the end of a line starting a block does not break this rule. I'd say it's even clearer when the code introducing the block is the symmetrical counterpart to closing bracket at the end of an indented block.

  • T Klöber
    T Klöber 5 жыл бұрын +6

    Excellent Talk! Very simple yet most effective ways of improving code quality!

  • Wouter Vos
    Wouter Vos 4 жыл бұрын +3

    Habits like putting Exception at the end of exception classes is to help programmers find exception classes in intellisense.
    Maybe we should learn other methods of finding classes than intellisense, like the object browser.

    • Alonso B
      Alonso B 11 ай бұрын

      That should be an IDE issue, as in those that derive from Exception should show up when typing Exception
      Or maybe for it to work like C# attributes, where when you use it, it loses the "Attribute" suffix

  • 7th CAV Trooper
    7th CAV Trooper 3 жыл бұрын +1

    In languages like C# combined with an IDE like Visual Studio, adding the word Exception to exceptions makes it possible for the programmer to discover exceptions within IntelliSense. You type in "throw" and a list of possible throwable things shows up. Type "Exception" and the IntelliSense list is filtered to only exceptions.

  • skilz8098
    skilz8098 2 жыл бұрын

    If you agree with everything I say, you weren't paying attention...
    I agreed with many of the things he said as most of them do make sense within some specific context. However, there are many things that I disagreed with... I'm self-taught in C/C++ and my main focus is within 3D Graphics Programming, Physics Simulations, Animations, etc. My next major interest is in Hardware Emulation still working in C/C++. Following that is a combination of Compiler Design and ISA Design(Assembler and Disassembler). This is just the software side of things... I also have an interest in the Hardware side of things which relates back to some aspects of the software side such as the ISA Design(Assembler and Disassembler) that focuses on the hardware design and implementation of the architecture. The final major topic of interest that I find myself looking into is A.I. programming and Machine Learning where I find myself diving into Python. I prefer to design and craft the backend portions of systems and applications as opposed to the front end such as Webpage development using JavaScript, HTML, CSS, etc... I like being closer to the metal with more control and with less abstraction, yet with just enough clarity to give my CPU or GPU the instructions that it requires to perform the tasks that I want. This now leads me to one of the biggest things that I do disagree with... The use of Singletons...
    If Singletons are designed properly and used within the appropriate contexts, they are very useful, powerful tools that also exhibit intent expressively. Considering that my main field of study and practice is within 3D Graphic and knowing that I will most likely be working in C++; I would design my application with a specific framework in mind. The main application or "user-front" will derive from an abstract base class which I just simply call "Engine"! If I have multiple engines for different things such as Sound, Graphics, I don't derive them from Engine to have `Engine::Graphics::Graphics()` as this is actually redundant. What I would typically do is have Graphics as its own object, Sound as its own object, Shaders as its own object, etc. The Engine class will contain all of those objects as the Engine is what Drives them all! Now, the Engine has to be able to store all of the Assets that are processed through those objects such as textures, sprites, fonts, models, skyboxes or skydomes, GUI elements, shaders, etc. which will give me various different types of collections and data structures from vectors to lists, to queues, dequeues, maps, multimaps, unorderedmaps, various kinds of tree structures such as BSP, Quad, and Octrees, a Scene Graph Tree structure that follows specific rules of what types of nodes can be nested under another, Batch processing, etc. With all of these integrated parts, I do and will have manager classes that specifically do just that but they are limited in number... I would typically have a TextureManager, FontManager, ShaderManager, AudioManager, AnimationManager as these classes are responsible for the storing of objects, checking if they already exist, return them when they are queried, removing them from the containers when they are no longer needed and cleaning up their memory, and to check if the data of the objects are in a valid state, has a valid range and domain. Now within my Engine class these are typically static pointers as all of these class derive from an abstract base class that is called Singleton. When this is designed properly, you can only ever instantiate one of those classes per application run. So if someone tried to do this:
    int main() {
    try {
    Application app(/*needed props*/); // Reminder: Application inherits from Engine and Engine is Abstract and is a Singleton!
    // If you tried to do this:
    Application app2(/*needed props*/); // This will throw an exception because an Application object named app was already created during this application execution
    } catch(const std::exception& e ) {

  • Zeturic
    Zeturic 3 жыл бұрын

    The "one true brace style" is "whatever your team is already using".

  • GRHmedia
    GRHmedia 2 жыл бұрын

    My primary use for comments is I'll wake up in the middle of the night with a solution get up program it for 10 or 15 minutes. Then go back to sleep wake up the next morning and look at the code and be dumbfounded. The comment is to remind why I did what I did. So far I've lucked out not one of these midnight half asleep programming excursions has been wrong. I honestly wish I could program as well when I am supposed to be awake as I do when I am half asleep. But once I've woken up and get what I did I delete the comments.

    MIGUEL ARCE 3 жыл бұрын

    I agree with most of the comments here. Some good ideas followed up with truly awful and insufficient explanation, unclear examples and unnecessary waffling causing me to zone out despite being interested in the subject. Teaching clearly and succinctly is as much an art as programming is.

  • basilio100
    basilio100 5 жыл бұрын

    This is "must watch and follow" video in my team. -)

  • Blind Spot
    Blind Spot 4 жыл бұрын +1

    Very happy with his first point about curly brackets. Been doing that against a tide of comment and even insults for years. For exactly the reason he stated, it's visually meaningful.
    The best point made against it is however: that's not how WE do it. Where I am excluded as a part of WE for convenience. There is very little one can do about that. Being right isn't everything, in fact it's nothing. Enrolling others is way more powerful and I have failed to do so. I fear he has failed to do so too, but I live in hope.. For now my code gets reviewed with very strange metrics in mind.
    This is the main reason I like working alone :)

  • KLH
    KLH 4 жыл бұрын +1

    Always loved that first point about my name... except for having to spell it a million times.

  • Paul Newton
    Paul Newton 4 жыл бұрын +2

    Use words like "exception" because you may know it's an exception but a future dev|debugger may not even know what "exception" is. Or be very explicit in your outputs with reference links to documentation

  • István Navrasics
    István Navrasics 3 жыл бұрын

    You definitely need code even if the code is clean. The code explains what you are doing. But sometimes it is not enough. You need to explain WHY are you doing that.

  • undercrackers56
    undercrackers56 4 жыл бұрын

    Some good points, but if everything he was ranting about was to be adopted then the resulting code would be a nightmare to work on as an outsider. Eg: We append "Exception" to an exception class so that it's function is immediately discernible when writing code within an IDE equipped with code sense.

  • Victory Chang
    Victory Chang 5 жыл бұрын

    Great talk!

  • muussis
    muussis 4 жыл бұрын +3

    I think this stems from programmers comparing themselves to plumbers than writers.

  • Nathan Smith
    Nathan Smith 5 жыл бұрын +4

    had some good points & anecdotes. he's definitely right that you gotta disagree w/ him on some points. like 10:20 when he falls right into a classic "thinking you're right because you've used the word 'fallacy'," fallacy. obviously having somebody express in a more natural way their thought process would help them express the intent of their code - likely they'll even come up w/ a clearer refactor when commenting it. conceptually, writing comments for convoluted logic should frequently help both current & future developers, for the same basic reason we find whiteboards & wireframing tools useful

  • Nick 111
    Nick 111 3 жыл бұрын +1

    Anyway nice talk!
    Baaki sab common problems aap logon ki... but yeah I wud like to emphasize 'get' 'set' thing. Seen lot of codes even if not programmed anything... and seen that very stupid way of using these constructs... where they just not even required or nothing more than just some more noise in codebase in your terms. Even in famous standard libraries or renowned compiler implementations.
    The think best use of get set is to denote a situation where u specifically want to do processing during getting or setting value of some data. Whatever it maybe doesn't matter... could be simple check or some complex thing.
    But if u not doing it... then its just another senseless stupid noise. U can very easily get set data through '.' operator on object instance itself. What's the problem?... its straight forward clean code...at it should be or use to be in first place.
    But if u define a get set method compiler should enforce its implementation...and should complain that that method is still empty during build or in error, warning or pending log ...whatever... if it can handle live analysis.
    I mean this way its implementation makes some sense...it adds a new feature... otherwise its just nonsense I suppose. Which is the usual norm currently how contemporary compilers handle those things or coders codes things. I think compilers should sensibly address this lil issue. Using it just for the sake of it or like some more stupid alibi that u can access it through like this or that construct or way of accessing thing doesn't make much sense. It should add something to value than making just some more stupid clutter only. And that's nice way to gel old coding style with new.

  • Efraim Globus
    Efraim Globus 5 жыл бұрын +3

    adding a common suffix to a class makes it possible to find it in the repository and therefore enables programmers to reuse code
    the same for adding get and set, when you want to inspect an object and understand what it exposes, having a common prefix for all the methods that serve the same purpose makes it much easier

    • Br Drnda
      Br Drnda 9 ай бұрын +1

      getUnits() purpose is to return Units, getCurrency() is to return the currency - it's a different purpose.

  • imAwesomeChris
    imAwesomeChris 5 жыл бұрын +5

    Wonderful talk.

  • Albert Batfinder
    Albert Batfinder 4 жыл бұрын

    This is a symptom of the luxury of modern programming. No restraints on memory, execution speed, bandwidth, storage, etc, so we pontificate on the placement of white space. Brunelleschi, in the fifteenth century, built a double dome of bricks on an octagonal base, the largest ever constructed; Steve Jobs wanted the Pantone company to create a new beige for his Apple II casing. They had 2000 beiges already, but none of them was good enough for Steve.

    • nix ix
      nix ix 7 ай бұрын

      Beige really is the ugliest of all colours tho

  • George Tsiros
    George Tsiros  Жыл бұрын

    29:10 I have no issue with _this_ being redundant naming. Exceptions are a special case and should be rarely seen.

  • Simon Masters
    Simon Masters 4 жыл бұрын

    Best talk ever!

  • Sun0fABeach
    Sun0fABeach 4 жыл бұрын

    I wish my company would value code style like this guy promotes. They pretty much don't care.

  • Daniel Jayne
    Daniel Jayne  Жыл бұрын

    Fantastic talk

  • ncardez
    ncardez 4 жыл бұрын

    Love the talk!

  • Larock1234
    Larock1234  Жыл бұрын


  • Holly Totallyarealname
    Holly Totallyarealname 4 жыл бұрын +169

    Professor: I deduct points for uncommented code.
    Me: //display the string

    • MirageOwl
      MirageOwl  Жыл бұрын

      I remember writing a whole page of comments and inserting a few lines of code in between for homework in freshman year :D

    • Suamere
      Suamere  Жыл бұрын

      Many different discussions about when To or NOT to write comments in code. I would rather see ZERO comments. Like I said, many discussions. But just like every child's question about "Why is the sky blue?" ends up with "Well, where did the Universe come from?"... so too does this discussion follow. And the end answer is Unit Tests. Your functional algorithms, where most comment enthusiasts REALLY push for comments, should be commented via its Unit Tests. a Unit Test method saying "If person throws corn then expect the sky to be blue". Your tests should explain your code. That becomes a Single Source of Truth.

    • Foxie
      Foxie 2 жыл бұрын +2

      Comments are for WHY, code is for HOW. When the code is too simple, it feels silly. But eventually you need them because otherwise readers waste time puzzling out WHY some things are the way they are. Your architecture decisions, your strange data structures, peculiar bugs.

    • e-Sharp
      e-Sharp 2 жыл бұрын

      @ernstig Since I wrote that comment - a year ago - I have read my share of papers. I still stand my position. Writing algorithms doesn't have much to do with writing applications. Both are very different fields. Therefore researchers are not qualified to teach any king of software development because they have never done it for a living. They only use programming at a syntactical level in order to express a calculation process. Most of the time it's pseudo code anyway.

    • ernstig
      ernstig 2 жыл бұрын +1

      @e-Sharp "researchers" invented most of the algorithms and wrote most of the successful programs you still use to this day. any researcher worth that name knows a lot more than just syntax

  • M SC
    M SC 3 жыл бұрын +2

    I would like to add to the things he said about the curly brackets, { and }.
    I have severe reading dyslexia. If you think he is making things up when it comes to readability, try again.
    Every time I see a code with curly brackets not on the same indentation for the same scope, I die a little of the sheer effort I must commit to in order to read just a few lines of code. Even though this effort practically disappears, if scopes are clearly made under the same indentation that makes it look far more uniform. Early exits help with this too, as long as it is in the very beginning of a function or method.
    Coding style matters dramatically for people with reading dyslexia, as it does not only effect them on natural language. I genuinely don't care about the quality of code as a reason to ask this of you.. I just want to be able to read your code without getting tired because the code is spatially all over the place.

    • Eric Johnson
      Eric Johnson 3 жыл бұрын +1

      I'm not at all dyslexic, but I can't stand opening curly brackets on the end of the previous line, either. The effort to look around to find where the block of code began is not worth the effort. My curly brackets have always lined up. It makes the code so much more readable.

  • Hinrich Aue
    Hinrich Aue 5 жыл бұрын

    Kind of a nice way to describe clean code. Not Sooo much new stuff

  • middleverse
    middleverse  Жыл бұрын

    Why are we never taught this stuff, such a good talk.

    • That One User
      That One User  Жыл бұрын

      @Lepi Doptera Sounds incredibly inefficient, lol

    • Lepi Doptera
      Lepi Doptera  Жыл бұрын

      Because you should be able to figure out the obvious on your own.

  • jérôme Barbier
    jérôme Barbier 5 жыл бұрын +1

    That man is brilliant! Impressive talk.

  • Handlebar Fox
    Handlebar Fox 3 жыл бұрын +10

    re: agglutinative terminology. My favorite was an event called "SomethingHappenedThatCouldChangeTheNavigationWizardButtons"

  • Christoph R
    Christoph R 5 жыл бұрын +68

    24:50 - I'd argue that Rindfleischetikettierungsüberwachungsaufgabenübertragungsgesetz is still a word, even if the law has been withdrawn. The fact that it no longer exits makes it no less of a word. That would be like arguing that "dinosaur" is no longer a word because there are no dinosaurs anymore.

    • Andre Brait
      Andre Brait 3 жыл бұрын +2

      I agree. But there are dinosaurs, though. Today we call them birds.

    • J JK
      J JK 3 жыл бұрын

      True, but the word itself is not and was never the "longest word" in german. You can always make up a word that is longer, but still has some meaning and is valid grammatically.

  • Magnus
    Magnus 2 жыл бұрын

    Was expecting a horrible video judging from the comments, but was pleasantly surprised. This talk is great - informative and enjoyable. Sure, the video editing could have been better, but come on. You guys know that you can pause a KZclip video, right? Honestly, I had zero problems following despite the code samples not being 100% visible 100% of the time. And "too much noise"? I guess some people missed that it's a talk, not a textbook or lecture.

  • greyreynyn
    greyreynyn 4 жыл бұрын +1

    10:31 also I would disagree that a programmer who thinks his code might be hard to understand without comments couldn't do a better job using english or whatever spoken language he uses. If you're using some framework that relies on a lot of knowledge of its semantics or internals, comments really help a newcomer understand.

  • Jedzia Dex
    Jedzia Dex 2 жыл бұрын

    Example at 6:40
    Left Side: Someone who clearly stopped learning C# at version 1.0. But Add-method is intuitive understandable.
    Right Side: Shorter, thanks to the use of higher integrated features. Needs the knowledge that Remove() ignores nonexistent items and the indexing operator throws by itself when out of bounds.
    Noise? Only relevant if someone does not use this as a black-box and has to maintain such code.
    In reality: Jim, he is dead! Let's use the next best library from XYZ that has a good rating and give a fuck about this one:)
    I know, I know. The librarians will hate me for this. But let's move to the next one:P

  • Never Code Alone
    Never Code Alone 3 жыл бұрын

    I like the topic and the content - thx for the video

  • Arek Górecki
    Arek Górecki 2 жыл бұрын

    Slides for presentation: www.slideshare.net/Kevlin/seven-ineffective-coding-habits-of-many-programmers-69941600. They are not exactly one to one though

  • Nathaniel Baron
    Nathaniel Baron 4 жыл бұрын

    I enjoyed the talk!

  • Tom
    Tom 2 жыл бұрын +1

    I disagree on the comment part. Yes, you can overdo comments and often they are just cluttering the environment with useless information. But they are actually useful for intellisense and peeking at references. People might get the wrong idea and eliminate them. Which is, in my opinion, bad practice if you're writing a lot of abstractions. Documentation blocks are absolutely necessary, inline comments are up for debate (but serve a function from time to time, when done correctly). Example: *// Code below equates to: a² + b² = c²* is actually useful information.
    The thing I actually find disgusting, when people use acronyms for everything AND don't even comment them

  • Vladimir Atamanov
    Vladimir Atamanov 2 жыл бұрын +6

    When I was younger I loved such videos. Each one of them was like a new revelation. "Yes! I always thought that way. This is so right." and so on. But then I start thinking if this is so good and obvious why there are still so many problems in this area? Nowadays I see too many issues with such talks. I will elaborate.
    First of all many points this guy has are kind of personal and more like a matter of taste. Trying to provide an argument to prove your taste is silly. Consistency is what matters. Another problem is that many points are laughably obvious. Seeing all these people seriously listening to the advice of not shitting without taking off your pants is just feels wrong. And the fact that it's happening is very very sad. And the most important thing. I strongly feel that these talks move people away from the real cause of the discussed problem. I will share my opinion on what it is. But I must say that this guy either does not understand it or is just hyping (like many others) on such problems.
    The fact that some codebases end up riddled with naming inconsistencies, redundant comments, misleading names, etc is because these lines of code were written by stupid developers who do not care. And unfortunately, there isn't much you can do about it. Doing this talk certainly won't change this a bit. You need what is called a "culture of programming" to avoid these problems. But to achieve that first you have to set a bar during the hiring process. Every project might have a unique culture but people who write bad code, don't see it and there's no potential for change.
    You need to share the same values with your colleagues for you to be effective as a whole. It is so easy and yet not many talk about it. I am not talking about the simply coding convention, development pipeline, etc. Feeling of what's right or wrong. Feeling of what's beautiful and what's ugly. Taste of what's good. Everything else will come to you naturally. Finding such a team or building your own is hard. This process is slow. It's not about just not seeing rationale as this dude thinks. It's about people being different.
    In conclusion, my key points would be:
    - Think about the common values of your team
    - Don't work with ineffective lazy idiots
    - Your's and your colleagues' uniqueness should not meddle with the consistency of the codebase
    - Use the same software tools and tweak them identically

    • pepineros
      pepineros  Жыл бұрын

      Excellent points! “Bad programmers write bad code” is really a straightforward problem, but slow and difficult to solve, so consultants like to stay away from it.
      I still found plenty of great points in this talk, but the idea of “All we need to do is explain it again and again slowly and carefully - programmers will catch on” is provably false.

  • Johnbosco Omebe
    Johnbosco Omebe 3 жыл бұрын

    Great talk

  • DarwinsChihuahua
    DarwinsChihuahua 4 жыл бұрын +1

    His section on Lego Naming makes me wonder if he's ever had to write and maintain a large-scale software application.

  • Techiesse
    Techiesse 5 жыл бұрын +14

    He won my like with the point about curly braces. :D

  • Danny Warnock
    Danny Warnock 3 жыл бұрын

    His final opinion on Curly Braces, which annoyingly flew by at 22:55, is a new line for Curly Braces. Which I personally find to be preferable and adds visual clarity imo. But I know Java and Javascript Devs may have a different opinion.