22 ms·

Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Sam

• tzahola 9y ago
  >Same way while/do/while is usually fades away, and if needed exit conditions. I couldn't interpret this sentence.
  • drawkbox 9y ago
    Edited, basically do not use while loops, if you do tread carefully and provide yourself an exit. You don't want to be the one that nukes the server.
    • RobertRoberts 9y ago
      I learned about while loops at the beginning of my career, and after a few scary errors, I never used them again. 20 years of no while loops anywhere... never going back.
    • contravariant 9y ago
      Dijkstra's approach towards provably correct programs has changed my opinion on loops somewhat. Among all types a 'while' loop gives the strongest mathematical guarantees. In particular it ensures a condition is true at the start of each iteration, and is false when exiting the while loop. Combining this with loop invariants leads to precise and straightforward to verify code. Avoiding while loops to ensure an exit just seems to be sacrificing a lot of power in exchange for some pretty shaky guarantees that your loop will finish. Although in the majority of cases where a while loop could be used you're simply iterating over some (implicit) data structure. In which case it's obviously better to make this explicit using a "for ... in" loop.
    • ajuc 9y ago
      Did you mean to use for with no counter instead? If so - I strongly disagree. I much prefer while(condition) {} to for (;condition;) {} For one thing you can't misplace ";" in a while loop. I agree that "do while" loops are unintuitive and rarely used, and thus the place to first check for bugs. Also they save very little so I just implement them as do(); while usually. But I know people who disagree about that, too, and shout at me for avoiding them:) It seems what's unintuitive for me isn't so for others.
      • drawkbox 9y ago
        Basically what I am saying is while should be mostly off limits. But yes if you end up in a loop you have some sort of counter/null checks or way out if you end up in a constant/recursive loop. Never leave open the possibility of a lock due to being stuck in a loop.
        • ajuc 9y ago
          You want to write "cat" equivalent. How do you do the loop? I think for loops should be limited to iteration over collections, or repeating sth known number of times. There are cases when you need to decide if you want to continue iteration on the fly, and while loop is the perfect tool for that. Also while loop is arguably less error-prone than for loop: can't swap clauses because there's just one, can't write "," instead of ";" by mistake.
• deleted 9y ago
  [deleted]
• deleted 9y ago
  [deleted]
• franciscop 9y ago
  Exactly, I did all of the above. Spent too many hours fixing broken code (of my own) and finally I started to learn. What about error handling? No mention here. What I do not is let the library/framework to handle most of it. With a recent server library I wrote, I can throw anywhere and it will be caught and displayed as expected without extra try/catch.
  • feedmeseymour 9y ago
    Errors are the exception, not the rule :)
    • RobertRoberts 9y ago
      Can't tell if a logical point or a pun...
      • feedmeseymour 9y ago
        The feeling is mutual; not exclusively :)
• Quarrelsome 9y ago
  > Same way you move on from heavy OO to dicts/lists. OO is better if the objects tell a story in a way that ProviderStrategyDataFetchers fail to do so and are effectively just wrappers for data structures. If you go pure data structure without story you just end having to add comments to explain purpose. The comments are the classes.
  • 3pt14159 9y ago
    I agree with both you and the OP. OO where necessary, lists and dicts where things are simple. You can always take a list of strings and turn it into a list of objects. But going the other way is harder because you have to refactor anything that depends on them.
    • Quarrelsome 9y ago
      The concern is when you encounter a list of very dense transforms between different data structures without anything informing you as to the purpose or even reason for these operations. Is it _just_ to build the output, are there critical side effects in the process? Are the apis just so bad that all these operations _need_ to be performed or is just pure 100% required processing? Method names help somewhat if people are adverse to objects. All that concerns me is that much modern functional code often becomes very dense transforms with little narrative to inform the reader.
• jrimbault 9y ago
  >braces go on the end of the method/class name to reduce LOC You could argue the placement of braces with lots of valid arguments both way, but this... to reduce LOC ? Doesn't feel like a valid reason in any language using braces...
  • fyi1183 9y ago
    Oh but it is, independent of the language. Fewer LOC means more code on the screen, which means you can more easily grasp the functionality of some piece of code, which makes it easier to maintain.
    • deleted 9y ago
      [deleted]
    • jcelerier 9y ago
      > Fewer LOC means more code on the screen, which means you can more easily grasp the functionality of some piece of code, uh ? for me the less code on each line and the easier it is to read
      • Dylan16807 9y ago
        When it comes to bracket placement, we're talking about empty lines. They don't affect the amount of code on a line.
      • collyw 9y ago
        That depends. Python's pep guidelines has an 80 char wide rule, but I personally find that a lot harder to read than one long line (most of the time).
        • extralego 9y ago
          I find the 80 chars too short but, and this is highly objective, I notice I am more relaxed and usually having more fun when working with shorter lines. The best theory a I have as to why is just that most lines in code are short so long lines require making my eyes deviate from the code structure. If there is a long line, it will probably be out of place. So, my personal rule is to avoid that one or two lines that juts out beyond the lines above and below it. If all lines in a block are long, they are often similar commands/expressions which makes them orderly, and not so discomforting.
• koolba 9y ago
  > Same way you get joy deleting large swaths of code. This is the true sign of a programmer's transcendence. Specifically the irrational joy of seeing net negative LOC diffs. It's not about how much you can add. It's about how much you can remove without sacrificing correctness, functionality, and readability.
  • allyjweir 9y ago
    "The only good diff is a red diff"
  • tren 9y ago
    "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
    • DonaldPShimoda 9y ago
      This is my favorite research quote from a Civilization game (Civ IV, narrated by Leonard Nimoy). I use this as my mantra for all design-oriented aspects of my life now. Or... I try to. Sometimes it's hard not to want to add more haha.
      • dv_dt 9y ago
        FYI that quote is from Antoine de Saint-Exupry, author (and pilot) famous for "The Little Prince".
        • eggpy 9y ago
          Do you know what the context of that quote is? I have used it as a sort of mantra specifically when programming, but I'm guessing it probably was intended for writing.
          • krallja 9y ago
            https://en.wikiquote.org/wiki/Antoine_de_Saint_Exup%C3%A9ry https://en.wikiquote.org/wiki/Antoine_de_Saint_Exup%C3%A9ry has the preceding paragraphs. It’s about the design of airplanes.
• anyzen 9y ago
  > Same way comments are extra weight that should only be in public or algorithm/need to know areas. This! Comments should convey programmer's intention and explain the thought process, not the code itself. Also, too many comments usually indicate that code should be refactored.
• sk5t 9y ago
  Oh sweet summer child. This list reflects but one possible course of programmer evolution. Some languages--and I'm thinking particularly of scala--encourage one-liners. Comments are rarely extra weight if there's anything worth explaining; access modifiers are not of the essence here. Collection types are no replacement for OO patterns that have a reason to exist in the first place. There's a good argument to be made that early exits, other than perhaps constraint checking, make control flow harder to reason about.
  • drawkbox 9y ago
    > encourage one-liners Less merge friendly as well. Also you should only do one thing per line when it comes down to it to increase simplicity. I like compact code but not adding complexity for no reason so others on the team can be confused. > Comments are rarely extra weight if there's anything worth explaining Good cases are non obvious flows and especially algorithms/notes or any section that will be public or generate docs from it. But mostly comments are weight not because they aren't good, but because they aren't updated and become out of date weight. > Collection types are no replacement for OO patterns that have a reason to exist in the first place. They definitely have a place but prototyping even they are better. They are the base of json/xml data formats and most languages. Everything on top of that should have a reason for complexity including OO as long as it improves understanding and simplicity. The "simple but not too simple" rule is what a programmer/engineer should live by. > good argument to be made that early exits, other than perhaps constraint checking, make control flow harder to reason about I'll fight to the death for better flow with early exits it is much easier flow with less indentation. There are times where you do need to go about it differently but most do not.
• edf13 9y ago
  Same as we now use TL;DR Exit or get out quick... make it readable... then the meat is left for those that want it below...
• Merad 9y ago
  > Same way braces go on the end of the method/class name to reduce LOC. Screw that. I've been writing code for 15 years, and Allman style braces make it so much easier to mentally parse code into blocks that they're worth every single LOC. I can't speak for anyone else but I'm not working on an 80x24 terminal anymore.
  • optimuspaul 9y ago
    Totally disagree with you.... it's funny though that I read LOC as "level of complexity" not "lines of code". I've been writing code for 30 years and I think it's jarring when the braces are on the next line, so much easier for me to parse that when it's on the same line. But everyone is entitled to their own opinion.
    • alunchbox 9y ago
      python fans are going like "what are braces?"
      • kabdib 9y ago
        That's fine -- the Python folks have their own share of religious wars (starting with: tabs, or spaces?) :-)
        • TomMarius 9y ago
          Tabs, everyone can configure them however they want. :-)
          • RobertRoberts 9y ago
            I hate being able to configure stuff, I want other people to boss me around from anywhere in the world! Their opinion matters on my computer!
          • tabbspace 9y ago
            Until you need spacing that isn’t a multiple of your tab width then you’re screwed.
• optimuspaul 9y ago
  > Same way comments are extra weight that should only be in public or algorithm/need to know areas. Unless you are writing completely brilliant code your future self will hate you if you skimp on comments. Also self-documenting code is great, but intentions are not always clear to another person trying to figure out your code.
  • Mithaldu 9y ago
    Comments are not documentation. Documentation explains HOW to use a thing. Good comments explain WHY a thing is strange. Bad comments explain WHAT a thing does and must be made redundant by extracting and naming the thing.
    • titzer 9y ago
      > Comments are not documentation. Probably overly generalized to be pithy, but no. Comments are by very definition documentation, which can and should cover of all of the what/why/who/how/where. Documentation that occasionally explains how to use code can actually be useful! Unless you actually get around to writing a user manual (which gets out of date), please do consider documenting how something should be used, particularly in libraries.
      • Mithaldu 9y ago
        As a Perl developer i mean this literally and transfer it to other languages as well. POD (or a block comment above a function) describes the API and use cases of the function. Inline comments inside the function exist only to provide explanation for the next maintainer when they see a strange construct. Any other type of comment needs to be refactored. Also, i never said documentation isn't useful. HOW and WHY are useful. WHAT in documentation and comments isn't because it should be in the variable/function/method/class/instance name. (Who/Where/When are covered by the source repository and the blame function.)
  • fouc 9y ago
    Only "brilliant" code ends up needing comments. Plain code organized into understandable methods (usually no more than half a page of code), with good naming for variables & method names reduces the need for comments. It's also easier to scan/read code if there's a minimum of comments in the way.
• ajuc 9y ago
  This is like the 10 commandments. Good ideas mixed with stuff that is a matter of taste :) If it was this simple we wouldn't be still arguing about coding styles decades after they were invented. I know few old programmers that I respect very much, and they don't agree about the perfect coding style, not even simple stuff, like braces in separate lines or not.
  • dhimes 9y ago
    If it was this simple we wouldn't be still arguing about coding styles decades after they were invented. Money quote.
  • ropeadopepope 9y ago
    > If it was this simple we wouldn't be still arguing about coding styles decades after they were invented. I disagree with the logic in this sentence. New coding styles are invented all the time. The guard statements in the article were only formalized in the late 90s, for example. These arguments about coding styles "decades after they were invented" are the only way we know which work and which don't. It's not a matter of taste. It's how you separate the wheat from the chaff. Except for the brackets one. ;)
    • ajuc 9y ago
      Late 90s were 2 decades ago :)
      • ropeadopepope 9y ago
        Guards were brand new in the 90s. Unless you're going to argue programming started in the 90s, your point is irrelevant.
• rawoke083600 9y ago
  "Same way comments are extra weight that should only be in public or algorithm/need to know areas. " Best thing I learned about commenting is: Comment WHY you are doing it... not WHAT. Code is the WHAT... Comment is the WHY
  • jimmaswell 9y ago
    If you feel the need to specify in a comment that the code does some potentially unexpected thing or that the way it does what it does has certain consequences, that's fine. And obviously the comment/doc of a function/class/whatever should say what it does if it's not 100% obvious and unambiguous from the name. I don't think this kind of rule is really helpful. Just comment if you feel a comment is needed, and if other people who interact with your code think you have too many or too few comments then you can adjust from there.
    • collyw 9y ago
      People do need to be taught this. I inherited a script from a co-worker who had left. My team leader had gone over it and commented it for me. # open file with open(my_file, "rb") as binary_file: binary_file.seek(8) No mention of what was at byte 8, or what the hell it was doing, but he commented the only obvious part of the code.
• deleted 9y ago
  [deleted]
• taneq 9y ago
  I've been coding about 20 years now, and I've seen all of these changes in my own coding style.
• psyc 9y ago
  For whatever it's worth, I insisted on single return for a long time when I was an intermediate programmer. 30 years in, I strongly prefer return early (as well as continue early in loops) and I cannot go back. The immensely reduced indentation is marvelous. Having that 'happy path' consolidated is more readable.
  • maxxxxx 9y ago
    I am on board with returning at the beginning while checking arguments. But I hate it when code returns somewhere in the middle for some reason. I have spent countless hours debugging a problem with unexpected behavior only to find a return statement in the middle of a huge block to code.
    • augustk 9y ago
      That's because the return statement is a kind of goto statement. Goto-like statements reduce the value of structured programming. In a pure structured program, each statement sequence is either completely executed or not executed. There are also pure structured languages, like Oberon, which doesn't allow impurely structured programs.
      • maxxxxx 9y ago
        When return is used in the middle of a complex code sequence I much prefer a goto so at least I know where all paths exit.
  • RobertRoberts 9y ago
    I find it interesting how most of the comments about return early are based on experience. I had the same thing happen about 10 years in. I just got sick of the extra coding and long indented blocks. And just switched over one day. Why is this not taught from day one?
    • macspoofing 9y ago
      The problem is that for any rule you come up with there are cases where that rule is just too rigid and too inflexible. There are times where early return makes a ton of sense. Usually that's the case when you can derive the return value from a shallow interpretation of some input values (i.e. check preconditions) but still require more complex processing for other input values. In that case, return early, but constrain the rest of the method to one return point. On the flip-side, there are cases where an early return makes it incredibly hard to reason about the function. This usually occurs in dense, nested conditional logic. In those cases, I found sticking to rule that a return value should be initialized once and only once, and return from a single point, beneficial in even reasoning about the problem.
• weinzierl 9y ago
  > Programmers with lots of hours of maintaining code eventually evolve to return early, [..] I agree with all your other points and I‘d even agree if you wrote return early makes code more readable but not that it‘s something experienced programmers do. Programming is still - to some degree - resource management. Inexperienced devs often miss that fact, because they are focused on memory management and believe they can rely on the garbage collector for clean-up. In real projects you quickly end up managing file descriptors, sockets, handles, GUI resources, etc. Early return is terrible for that, because your coding style starts to depend on the kind of resource to manage. That‘s why the more experienced folks end up writing single exit point code sooner or later. EDIT: I‘m not arguing that early return and proper resource management are incompatible, just that most experienced programmers have often been burnt enought to avoid it.
  • monocasa 9y ago
    That's one of the reasons I love RAII; all resources, memory and otherwise, are treated the same.
    • jasonmaydie 9y ago
      it's not just about in app resources. This could also affect external resources.. like not cleaning up temporary files because a future maintainer returned early and left some critical data behind.
      • klmr 9y ago
        RAII can handle such resources, and good use of RAII does handle such resources. Languages without time-deterministic GC even tend to add extra language constructs to aid this, such as `using` in C# and Java (7?) with its new `try` block.
    • weinzierl 9y ago
      That‘s what I was thinking when writing my edit. The somewhat ironic thing is that C++ people could use early exits safely, but often don’t, while Java folks typically write early exit code when they really shouldn’t.
• projektir 9y ago
  I'm waiting on the jury for Almost Always Auto...
• kruczek 9y ago
  > Same way you evolve out of one liners. > Same way braces go on the end of the method/class name to reduce LOC. For me, these are exact opposites; the reason to not use one-liners is the same as the reason to put braces in separate line: both improve readability.
• vpribish 9y ago
  Wow, you captured so many things I saw in my own education. let me add one: Same way you learn to let some code fail instead of handling every exception.
  • your-nanny 9y ago
    In my case, half the time I don't know how to handle the exception usefully, and the other half of the time hard failure is the better option. But that's mostly for data analysis.
• nippur72 9y ago
  > Programmers with lots of hours of maintaining code eventually evolve to return early indeed I've evolved it myself but always wondering if it was the right thing to do. Now I even have a name for it.
• kbenson 9y ago
  > Same way you move on from single condition bracket-less ifs. This is one of those things that whether you drop it or not, you recognize the times it's caused you severe pain because you didn't notice it was single line when adding a statement, such as a debugging one, and all of a sudden the conditional part isn't what you were expecting. This is actually one of the things I love about Perl. Single line conditionals were changed so they both looked different, and they only allow a single statement. e.g. if ( condition ) statement; becomes statement if condition; Regular if blocks still work as expected, but there is no braceless version of regular if conditions. I understand many people find it jarring at first, but it does allow for clear and concise precondition and return early statements, especially when grouped together. e.g. return undef if $param1 < 0; return undef if $param1 > 100; die "Not a number" if not looks_like_number($param1);
  • collyw 9y ago
    This can be horrible in JavaScript. It can make code really ugly. I have had to deal with code that looks like this recently: if (condition){ doSomething() doSomethingElse() } else doSomethingDifferent() doSomethingConfusing() // is this part of the else or not?? Perl got many things right. Its a shame it seems to have fallen away as a language.
• macspoofing 9y ago
  >programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. That's not true. Sometimes, the code begs for an early return so you can focus on the meat of the method. Most times, that's not the case. Single return conditions should be the default, and you should have a good reason not to do the default. In Java, for example, if you also stick a 'final' on the uninitialized variable, you have very nice compiler check to enforce that every code-path initializes the variable once and only once. Sometimes that is also too strict for what you want to do, so you can break the rule, but you have to have a good reason. >Same way braces go on the end of the method/class name to reduce LOC. No. Just no. Not for that reason. >Same way you move on from single condition bracket-less ifs. (debatable but more merge friendly and OP hasn't yet) It's only debatable by people who are just used to it, or who want to minimize LOC for insane reasons. It's non-debatable in that it is a very common vector for bugs to sneak in. Over the last 5 years, there were probably as many bugs stemming from bracket-less ifs in our codebase. >Same way you move on from heavy OO to dicts/lists. You start introducing another common vector of bugs for a little flexibility. Sometimes that may be worth it. As a general rule, it's not worth it.
• hutzlibu 9y ago
  "Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom." I generaly don't like when one person says (declares) how experienced persons act, but in this case I have to confirm with myself, as I also "evolved" to it and I tend to program in isolation, so I am no influenced by others so much.
• mnm1 9y ago
  After twenty-five years doing this, the only thing I would say is that the style points you mention above are completely irrelevant and the points that refer to actually writing code mostly correct. Programmers that have been programming a long time and are skilled should know the difference between the two types of points and not confuse them as equally important as you do. Also not writing comments because the code seems obvious when you're first developing it is totally a rookie mistake. Codifying it in rules is a sign that the programmer simply doesn't understand how the human mind works over long periods of time. No code is self documenting after six months away from it. None.
• pmarreck 9y ago
  I've actually gone from avoiding else to requiring else, which is sort of a necessity when you're in a functional immutable environment where the result of a logical expression is a value (and often assigned as such), since it avoids undefined situations. (This example comes from Elixir.) value = if boolean, do: this_value, else: other_value is undefined in some circumstances unless an "else" is included. This pattern might seem weird to OOP folks (the assignment, not the ternary-operator-style logic), but in Elixir-land, it is not only considered superior to assigning inside if/then logic, you actually get a compiler warning if you assign/bind to a variable inside a logical expression because (again) that value becomes undefined as soon as you leave local scope (or re-acquires the value it had in the outer scope, thanks to immutability). And if you think about it, values can only travel in one direction using this scheme, which further simplifies reasoning about information flows. I would argue that this is also superior to early-exit as having one entry point and one exit point is much easier to reason about, and because the extra logical complexity you're ostensibly trying to avoid writing by early-exiting is actually still there, it's just obfuscated... and that complexity should be made obvious (in which case, if it's extensive, it would be a code smell... consider the example of a function with 25 early exits that "looks flat" visually, but which actually has 25 different branches)
  • Kapow 9y ago
    That's just a ternary operator. I use that in Java all the time. value = boolean ? this_value : other_value; If the branching logic gets too complicated, I usually move it into a function (private method) with a return in each branch.
    • crooked-v 9y ago
      And in Javascript, once do-expressions go from a proposal to a common part of the language, this will be a thing: let value = do {if (boolean) { this_value } else { other_value }} ...which is even closer to the Elixir style than JS's ternary operator (which is identical to Java's).
      • aiham 9y ago
• gigatexal 9y ago
  I find myself doing the same for many of these points. I wonder what the point is then to hit OOP so hard in CS majors if at the end of the day production code isn't written like that. I guess my question is more the validity of seemingly esoteric concepts when practical programming evolves to the list in the post by drawkbox.
• jimmaswell 9y ago
  Can you give some examples of replacing OO with dicts and lists? I've made classes or structs to make it easier to manage what a few associated lists/dicts were representing, but I'm not sure I've done the opposite. Maybe using lambdas instead of subclasses?
• hamilyon2 9y ago
  Some of theese are debatable and others, like set operations, are missing
• xg15 9y ago
  > Same way you move on from heavy OO to dicts/lists. Is that a thing? No question that many concepts of OOP are in heavy need of reform, but I didn't know the basic idea of a struct was one of them. I can sort of imagine this for quick-and-dirty things in untyped languages - but if you have types, passing dicts around everywhere seems like needlessly throwing away type safety - while it's also cumbersome to code and less efficient at runtime.
  • brianpan 9y ago
    I think this might partially be related to the move towards streaming applications and microservices. You could create objects for everything you expect to receive/send and then when an API changes you lose the new fields, you get parse errors, etc. If you did it right maybe you can avoid some of those things, but the bottom line is that type safety is a little bit too strong a constraint for these use cases. Even if I'm getting from a DB which won't be changing out from under me, many times I'd prefer just getting a simple Map rather than spending time creating a "safe" object. Do I create a User and UserWithDetails? Or always return UserWithDetails but sometimes fields are empty because I don't care about them? Dicts are light, objects are cumbersome.
    • boomlinde 9y ago
      You can of course create a User and a UserDetails, the former embedding the latter when necessary. I also see getting parse errors when APIs change as a positive thing. When you change an API, things do break. Learning what breaks as early as possible is good. It's not even about objects vs. dictionaries, you could use any structured composite datatype and the overhead you associate with it depends very much on the language. Of course, for a quick hack I'd happily dump data into a dictionary and call it a day. But if I want to learn why it breaks 5 years later, having a clear specification of the expected data is much better even if it cost me an extra few hours.
  • okbake 9y ago
    I'm a fan of TypeScript's structural typing for this reason. I can define an interface that describes the shape of a "plain old object" (it's fields and their types), and then write functions that accept/returns an object of that interface. What's great about structural typing is I don't have to explicitly say "create a new object of this type", any object that satisfies the shape of the interface is valid (object literals for example). So you end up with the best of both worlds (in my opinion), where your state is made up of simple plain objects and you behaviors are just functions that accept simple plain objects, but you get all of the benefits of compile time static type checking because they are checked against the interface.
• bsder 9y ago
  > Programmers with lots of hours of maintaining code eventually evolve to return early, sorting exit conditions at top and meat of the methods at the bottom. Except that I see soooooo many people try to write state machine code with early return/function encapsulation just to avoid indentation. And then they get pounded when the state machine needs to evolve--and it always needs to evolve. I really wish programmers had to design a VLSI chip, get it manufactured and debug it just once before they get out of school. The "So THAT'S why they have a global clock that synchronizes all the parallel operations in lock step" moment tends to be blinding.
• Kluny 9y ago
  > Same way you go more composition instead of inheritance. What does that mean?
  • Noumenon72 9y ago
    Basically instead of Subtype extends Type inheritance, you just give your Type class a SubtypeHolder field. Makes it easier to add different behavior as things' types become less similar than you expected.
• Xyik 9y ago
  this is so true, and my experience exactly. one thing i do disagree with is commenting, there is a time in a place and its hard to derive on a rule on exactly where, when and how, but well placed comments are VERY important and can save developers a ton of time.
• anonytrary 9y ago
  You guys just made me feel better about myself! Thanks, HackerNews.
• eecks 9y ago
  I've never thought about this before but I nodded with agreement with each point.
• codehalo 9y ago
  All good arguments except for the end braces/LOC one. The visual cue is worth far more than the one line it takes up.
• edwinyzh 9y ago
  Anybody has an example for "Same way you move on from heavy OO to dicts/lists"?
• boomlinde 9y ago
  My experience, on the contrary, has left me thinking that none of these are absolute. You apply certain constructs and styles where they make sense—which depends on what you're writing and who you're writing it with—and become increasingly suspicious that people who appeal to absolutes simply haven't yet encountered situations where the trade-offs ultimately balanced out in favor.