As I stated in my previous post, working with other developers is an area where I struggle, both as a leader and as a member of a team. As an introvert and possibly slightly autistic, interacting with other humans at any level can be difficult for me.
I know my struggle is common. This industry tends to attract the misfits like me that prefer the logical interaction with 1's and 0's instead of the messy analog world. Unfortunately for us misfits the days of the lone programmer in a dark corner of the basement accomplishing something no longer exist. And possibly never did. It takes a team to accomplish something. And despite that "unfortunately" above, I think that's a good thing.
Good thing but challenging. Over the years I've gotten better at interacting with others. My current job has actually helped with identifying areas where I could improve and learn. But it's also been very frustrating at times. I'm also a perfectionist with a little OCD, so it can be really difficult to tell whether I'm someone who pushes for quality or just an arrogant nitpicking asshole.
Which leads me to my question for today. I've been struggling - and procrastinating - on how to continue from my previous post with some of the issues I've been struggling with. Then I ran into something last week that felt like a good starting point. Does your team have a formatting standard? And maybe more importantly, how do you enforce it?
For that last question, I believe that the actual answer is you don't. There are multiple ways such as linting to automatically clean up code before it is ever committed. But to highlight the first challenge with my shop, we can't even agree on tooling. We're a .NET shop, so we primarily use Visual Studio Professional. I remember once mentioning in a meeting that a simple keyboard shortcut - Ctrl-K,Ctrl-D - handles the majority of the formatting clean up for you. The response I got from one person - the one I consider the sloppiest as well - captured the problem perfectly: "I don't have time to learn new keyboard shortcuts.".
Which version of Visual Studio we use has been a continual source of conflict. It's only been a couple years since I managed to get us to switch from VS 2010 to 2015. Let's not even mention the arguments over the last year around switching to VS 2017. Some of us have switched (like me), but for the most part, VS 2015 is what is expected to be used. That leaves out the option of taking advantage of using .editorconfig. I did create one for all the projects I'm responsible for so at least those who use VS 2017 will be affected. I know there is an extension for VS 2015 to add support for .editorconfig. For that matter, I've personally been using CodeMaid which would work in either version. But I haven't even tried starting a discussion over what extensions everyone should be expected to be using. I already know how that discussion would go.
Let's get more specific. I have a codebase that I'm been the sole developer on for several months. Another developer has recently started working on it while I'm on a different project. To protect the guilty (ok, I'll be nice - innocent), let's call him D. D has been in the business for decades. He once worked at Compuserve as an example. And D is the biggest point of conflict for Visual Studio versions and other areas. But one point that he does repeat that I actually agree with is consistency. In some of the discussions we've had regarding a formatting standard, he has stated that it is more important to be consistent with the existing code. Except, I guess, that doesn't apply to him.
This is one example of how I format my code and is how everything is formatted in this codebase.
In the code that D has been submitted, he's used two different formatting styles. I also find it "interesting" that he doesn't always follow the C# convention of Pascal casing for the property names. I know that class is meant to represent a database table and that table probably has columns capitalized that way (and yes, that database is that horrid but that blame lies elsewhere). But I don't know if he realizes that capitalization mismatches won't matter or if he's thinking he has to match the capitalization because "reasons".
Based on previous discussions with D, if I bring this up with him, the most likely response I would expect to get is that it doesn't matter and that it's more important the code works than that it's consistent or "pretty". What do you think? Do I need to turn down the OCD a notch and just let this go? How would you handle this situation?
Top comments (8)
You should have a chat with all the devs, setup together an automatic code formatter with a satisfactory style and a linter. The linter/formatter has to run at every commit.
Then you can forget about code styling from then on :)
I agree. We've tried a couple times to come up with some kind of consensus but keep failing. I don't even think I could get everyone to install CodeMaid which would solve the majority of the problem. I've been seeing this issue as a symptom of bigger and deeper problems with this shop but haven't been certain it's more me than anything else. These responses have helped.
I'm happy you're aware that the fact you're having troubles to find a consensus about something trivial like formatting might be an indication for bigger "people problems". If they truly think working code is more important than formatting issues (and in theory that's true), why are they then so opposed at having both? It's not like well formatted code changes the code behavior...
I think it could be best described as a combination of not willing to put in any extra effort no matter how minimal and not willing to accept anything coming from me. Especially if the latter means having to do the former.
Is very important to have a formatter with rules that get enforced either when files are saved via IDE tools or when committing code to the source repository. The rules should also be kept in the repository alongside the code. This way there is no room for discussions and nobody has to think about it, code gets formatted, period.
We have a NodeJS codebase, and we are using Prettier for formatting, enforced on a GIT hook when we commit the code.
Thanks for the response. I do have my rules documented and in the same repo for my projects. But one challenge is getting people to read and follow them much less trying to implement something that requires action on their part. It's also nice to see at least one place that both recognizes the value and has taken action to make it a non-issue.
Doesn't matter that much what your style is, as long as it is applied automatically and the linter doesn't just harass the programmer.
I find your last remark curious, as I sometimes feel like having the "wrong" capitalization for the language is the "right" thing to do when using external sources.
For example, when writing against this Zigbee spec, in JS/TS I feel like having a named parameter
args.AckedTransitionsmay be superior to renaming it toargs.ackedTransitions.Am I redacted? Should I commit toaster bath?
Thanks for the response. Regarding your capitalization, if that works for you and your team, then I don't have a problem. For me personally, I find it visually jarring when something differs epecially when there are multiple capitalization methods in a single class. In the C# world, I think mixed capitalization is not very common. As well as Visual Studio 2017 with .editorconfig can define capitalization conventions and flag violations with a warning. Which I've done so these would have shown as warnings for D if he were using VS 2017.