1. 20
  1.  

  2. 20

    And, yes: An interesting discussion can be had over the merits of tabs versus spaces, or the merits of braces before or after the newline.

    This one is what gets me. In a larger sense, I think these conversations are manifestly uninteresting. I’m such a fan of the new wave of automated source code formatting because, by and large, I don’t want anyone to be having conversations about this stuff. It’s quintessential bikeshedding.

    I’m happy to engage in these conversations from an “it’s fun to discuss things” point of view. It’s also worth spending a little time on it early on and as teams scale to keep people on the same page and incorporate feedback. But I’d coach a “new developer” to look past these details and find the much more interesting conversations to tap in to instead.

    1. 1

      I’m happy to engage in these conversations from an “it’s fun to discuss things” point of view. It’s also worth spending a little time on it early on and as teams scale to keep people on the same page and incorporate feedback. But I’d coach a “new developer” to look past these details and find the much more interesting conversations to tap in to instead.

      God yes, my only contribution as a non newbie now however: don’t be afraid to introduce some sort of standard. As someone that got clang-format setup and implemented into a 20 ish year old c code base with around… 5 different styles of c, its worth it.

      And the benefit of then being able to enable pull request middle fingers for people that didn’t run clang-format on their prs is golden. Edit it however you want in whatever style you like, just make sure to format it before you do the pull request.

      I don’t care what style gets used, as long as there is something that is automated that can fix up whatever garbage I typed into the approved style. (it also showed us that there were too many damn macros, some 4 levels deep, we cleaned that crap up too, overall it was a huge help)

    2. 10

      I appreciate the sentiment of not trying to change a code base’s well-established and consistent style. However as a manager, the deference to more “senior” developers/managers/Apple/Microsoft in this essay is not a desirable trait in a new teammate.

      Good junior engineers ask good questions that reveal blind spots that “senior” engineers and managers have long had. Thoughtfully and tactfully press issues and ask questions, junior folks. Everyone more senior than you have more blind spots than you can imagine. But also know that senior folks will often hide behind the shield of their seniority, and you should know when they’re putting it up. If possible, avoid those people. If it’s not possible, hone your tact and use a different angle to make your case. These skills that some people call “soft skills” will get you very far in your career.

      1. 11

        Good junior engineers ask good questions that reveal blind spots that “senior” engineers and managers have long had. Thoughtfully and tactfully press issues and ask questions, junior folks.

        Good point. It’s a line to walk. You have to choose what battles to fight, however. I think, for example, questioning which data store is a good fit for a greenfield application is a better way to spend your effort (as a new dev) than tabs/spaces.

        1. 1

          Indeed!

      2. 7

        I’m not even convinced that inconsistent style warrants discussion. Is there any evidence that mixed-style code is significantly harder to read? I think compared to things like good documentation and naming whether it’s

        void frobnicate(foo* bar) {
        ...
        

        or

        void frobnicate(foo* bar) 
        {
        ...
        

        isn’t going to slow me down at all.

        Either way, automatic reformatting is indeed probably be a good solution.

        1. 20

          I personally disagree — inconsistently formatted code causes me significant distraction. Yes, even braces on the “wrong” line.

          I mostly wish that weren’t the case, of course. OTOH, though, if that part of my brain were “fixed”, it seems likely it’d reduce my ability to be the “details person” on my team that catches all the little typos/subtle logic bugs before they ship.

          1. 4

            I think it’s less in the example you give (which is pretty straightforward) and more calling out something like this:

            void frobnicate(foo* bar)  {
               if (abc) 
               {
                   } else if (def) {
               if (ghi) {
                   }  
               }
            

            If you have enough indentation, I find it confusing.

            1. 4

              I agree. Ultimately it’s a non important detail. We all have preferences and different styles have their advantages and disadvantages. Hence the reason they exist. I’ve seen this taking 25-75% or the effort and time put into reviewing code. Often above 50%. Whatever importance this has, it is tiny when compared to what the code actually does, regardless whatever style it is written in.

              1. 3

                For me, it’s like reading a novel vs a variety of websites with different styles. I can surely get through either, but the former’s consistency reduces my effort significantly.

                1. 3

                  Is there any evidence that mixed-style code is significantly harder to read?

                  Speaking as someone who actually has worked on code with inconsistent formatting … not really, no. Usually.

                  On one project I worked on, each developer largely kept to their own directories, so everyone just kept to their own preferred style. Later in the project, though, we all finished the main work and started venturing outside of our little fiefdoms to fix bugs and whatnot. I would painstakingly write in the formatting style of whatever file I was in, at first, but then I noticed that nobody else seemed to be doing that, and over time you would see more and more places where the formatting style would abruptly shift for five lines. I found this deeply ugly, but apparently it didn’t bother the others enough to stop doing it. (Indeed, one engineer joked that it provided an instant fingerprint of who touched the code last, without having to look at version control.) So, it was annoying to me, but it didn’t really slow down comprehension.

                  However, another project I worked on was run by a bunch of novice engineers with no consistent style. One day I wasted a bunch of time trying to debug a very long function before finally realizing that, through the course of modifying the code, the indentation had gotten out of sync with the braces depth, meaning that the end of an if block was actually dozens of lines off from where I had been reading. Only the lack of a consistent style (and primitive text editors) made such a glaring mistake possible.

                  So, I’m more inclined to say: it doesn’t matter, until it does.

                  1. 3

                    Agreed. A sufficiently advanced code base will contain not only mixed formatting but mixed programming styles. Some parts will favor composition over inheritance, another might’ve been written in a semi-functional style.

                    Yet other parts of the code will have been written at a time when certain language features weren’t available, like Java Collections or unique_ptr. It’s your job to read and understand all of them.

                    If inconsistency is something you can’t tolerate, then you’ll have a long and unproductive career ahead of you. Maybe programming isn’t the right job for you?

                    1. 2

                      I agree it’s a small thing, but it’s the principle that’s important.

                      Consistency only works if you’re consistent with it. :)

                    2. 6

                      What’s important is that the codebase is readable, and keeping a consistent tabbing and bracing style is more

                      Agree.

                      If your team does agree to change the tabbing and/or bracing style, don’t do it gradually. … Instead, use an automated tool to reformat the code.

                      I understand this point of view, but it is also important to mention that this destroys the history in your version control system (mercurial, subversion, git, fossil etc.). The annotate/blame tool will become useless and will point to a single person (often the junior developer who was assigned this boring task), you will lose the information why particular lines were written, by whom and when (of course, the information is still stored somewhere in the history, but is is practically inaccessible now). It will be difficult to distinguish important changes from formatting. And if you develop in multiple branches and merge or cherry-pick across them, the automatic process that usually runs smoothly will fail now and will require expensive human work… just because the older branches/versions have different formatting.

                      The correct solution would require a complete history rewrite. Literally rewrite every single commit, reformat its code while keeping the author, date and message metadata unmodified. But: this is so many commits, so many years… in a distributed version control system, it changes the hashes, so if someone from outside references to them, this references will become invalid (e.g. links from external websites)… or there might be a bug in the formatting tool that makes some significant/logical changes in the code – then if a customer asks you for a „v3.0.0 with just a small fix“, he might get completely different version with many other changes… I am afraid that the risks are higher than benefits.

                      Perhaps suggest a style that a well-known open-source project uses, or a well-known style guide published by Microsoft or Apple.

                      I recommend talking rather about free software than open source and avoid promoting evil corporations.

                      1. 3

                        “The good thing about standards is that there are so many to choose from”.

                        Anecdotally, GNU C formatting is one of the less popular styles.

                        I’m neutral towards Go but I do appreciate that the language designers shortcircuited a lot of debate and saved countless wasted hours arguing by including a formatter in the language.

                        1. 1

                          of course, the information is still stored somewhere in the history, but is is practically inaccessible now

                          Do that many people know enough git to use blame but not enough to know git blame <revision>^ -- path/to/check?

                          I don’t expect many people to know how to use blame but I’d (perhaps wrongly) assumed that those who do could navigate more than one layer of history with relative ease.

                          1. 2

                            You can also

                            git config blame.ignoreRevsFile .git-blame-ignore-revs
                            

                            so that revisions listed in .git-blame-ignore-revs are automatically ignored by git-blame in the future.

                            1. 2

                              I didn’t know that command line invocation! Looking at github, the blame page looks something like:

                              commit header (with link), date, link to blame at that commit, line number, code

                              The commit header link, and the previous blame version, are useful in navigating changes.

                              1. 1

                                I don’t use git blame; my editor always shows the latest change for every line.

                            2. 4

                              Automate with a linter/formatter or GTFO.

                              Every junior developer should be demanding this and it should be their first pull request if they know how to set it up when they encounter a code base that does not have it.

                              1. 12

                                I would encourage junior developers to consider not making a bombastic splash as their first commit. There is value in appreciating the culture you’re entering before trying to take charge, and you get exactly one chance to make a first impression.

                                1. 5

                                  I was just talking to someone who said you should treat the people showing you a codebase just like you would a tour guide of a new city you are exploring.

                                  Questions? Kind comments? Fine.

                                  “You should do it this way, because that’s how we do it in New York City”? Probably not going to be received well, or even heard.

                                  (I pick on New York City because of a childhood watching salsa commercials: https://www.youtube.com/watch?v=vbp9UrwC-mI )

                              2. 4

                                I once pointed out to a new developer that I use git blame when something doesn’t work, and whoever touched the line last will have to answer first. So by changing virtually every line in the project, every bug is now yours.

                                1. 3

                                  So does anybody have favourite formatters for C/C++? I’ve been trying clang-format but it, for various reasons, is imperfect. Those reasons are, briefly:

                                  • version skew across the dev team (not everybody has the latest installed and older versions simply choke on new things in the config file)
                                  • formatting “surprises” (unless you’re willing to accept giant corp’s style, have fun making a config file that does what you want across all the weird things your team will throw at it)

                                  My ideal tool would accept a giant hypothetical C/C++ file(s) as “correct” then learn and generate a config file from it. Yes, I realize I’m asking for a unicorn.