Sek Thoughts On Classic Code Battles

Geeks (most solid programmers tend towards geekiness) like to argue about seemingly mundane stuff. Arguments about code

Tabs vs Spaces

  • Tabs
    • PRO:
      • single arrow key to go from one indentation level to the next
      • viewers can choose the indentation level
      • smaller file size (in bytes)
    • CON:
  • Spaces
    • PRO:
      • author can choose indentation
    • CON:
  • SEK sez
    • I can see both sides on this one, and have osilated on this over the years
    • Breaking it down:
      • I don't think viewers should have / need to have the power to use their own indentation level - that should be the authors choice
      • arrow key navigation can be important - if spaces are better though, the best solution seems for the editor to handle the arrow navigation better
      • file size difference should not matter in this day and age
      • mixed styles in a single file is an order of magnitude worse than either extreme. That's the problem which really needs to be avoided. I know of only two ways to get close to 100% elimination of mixed style files
        • standardize team editor with an automatic formatter, make it format on save and never disable the autoformatter
          • unfortunately eclipse's auto-formatters are not nearly as customizable as I'd like to make this a hard ruleā€¦ SUCKS!
        • have a format check or formatter when code is commited to the shared repository - this is often cumbersome / inconvenient at exactly the most stressful moment, and therefore hated
      • Having said that, spaces are what make more sense to me right now (march 2010)

braces on same line vs braces on next line

  • braces on same line
    • PRO:
      • file is not as long
      • can fit more code on a single screen
    • CON:
      • some people don't like how it looks
  • braces on next line
    • PRO:
      • makes it easier to temporarily comment out certain things (ex: an else clause that you want to try the code without)
      • visual preference of some
        • braces line up vertically
        • more "airy" look to the code which some prefer
  • SEK sez
    • I prefer braces on same line. I think that how much code can fit on a single monitor screen is very important. In some cases this difference can cause a 20-50% increase in how much can fit on a screen and a half. I also would rather that the programmer spend a bit of extra time to make the code look shiny and clean even with the braces on the same line (even if it does take more time). I think this fits with my feeling that code is artistic similar to how writing is artistic

Dynamic vs Staticly typed langages

  • Dynamic
    • ex: Ruby
    • PRO:
      • More productive, more concise
  • Static
    • ex: Java
    • PRO:
      • Nice Compile-time type checking - including generics - in concert with a powerfull IDE, this can eliminate many painful runtime exceptions
  • SEK sez: I can see both sides and I think this one is a different tool for different uses. Both have strengths and weaknesses.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License