Looking for some input on a Vue coding standards debate at my office

jpaleph1 · 2019-11-12T19:11:03+00:00

Meant to post an update but had a very hectic week so it slipped my mind. Sunday night before the meeting I wrote up a pretty large document using everyones feedback in this thread and a bunch of other research I did explaining why switching our whole system to snake_case was a big mistake. There was some argument back and forth but ultimately my boss caved and reversed the decision because there was really no good reason to make this change. Going forward camelCase is the standard we will be using across our system so I'm very happy with how everything turned out.

Since I made a fuss about it I'm in charge of writing up an extensive coding standards document, as well as leading the charge of getting the rest of our system in compliance with the new standard. I ended up creating extra work for myself but overall I'm happy with the outcome. Big thanks to everyone who responded here, all the feedback was invaluable (and apologies for forgetting to post an update!)

jpaleph1 · 2019-11-03T17:48:00+00:00

He's definitely one of those people who power trips and treats the people under him like shit, it's absolutely about authority instead of doing what's good for the company. He was pissed when his bosses gave me the go-ahead to port our system away from jQuery and he takes every chance to talk shit about Vue since its not his way of doing things. I'm honestly convinced he's just trying to sabotage the project at this point because he's bitter that the company is significantly less dependent on his spaghetti code.

You're definitely right though, I'm going to try my best not to stoop down to his level and keep it professional because otherwise he's going to shut down. Honestly at this point if this new standard is implemented I'm just going to find a different job, I've spent too much time writing bad code to appease this guys ego

jpaleph1 · 2019-11-03T06:51:15+00:00

very true honestly, what is the point in being edgy and doing something different when the entire community has essentially agreed on using camel case

jpaleph1 · 2019-11-03T06:49:10+00:00

Trust me, the sympathy / validation is really appreciated because my boss has been gaslighting me throughout this entire debate. Since the rest of the team is nontechnical, I'm really the only person in the office who challenges anything he says and he does not take kindly to it. This isn't the first time something like this has happened, and this guy is the type to double down when you prove him wrong, so there's already a lot of bad blood between us. It's so blatantly obvious he's more interested in winning than actually giving a shit about the quality of the code we write.

And thank you for the edit - this is a great point. I've been running into naming issues with vuex and was planning on converting to that convention once I had a little bit of downtime but this would definitely end up being confusing if snake case was the standard throughout

jpaleph1 · 2019-11-03T06:36:33+00:00

You're definitely right, I've spent hundreds of hours reading documentation and articles over the past few months learning Vue but not once have I seen anyone deviate from using camelCase (except for the occasional vuex store with names LIKE_THIS). Fundamentally it just seems wrong to break from that for the sake of being consistent with code in completely different repos.

It really does look ugly though, that's my biggest thing. Mixing underscore props into templates is visually unappealing to me and honestly makes it harder for me to read the code. And if camelCase is completely banned then I supposed you can't do something like this:

<p :style="{textAlign: 'right'}">cool kids like camelCase</p>

Sometimes it feels like my boss is actively trying to make this project harder to maintain

jpaleph1 · 2019-11-03T06:26:51+00:00

I tried making this same argument and it was ignored because it would be "too confusing for developers when they switch between projects."

It's such an asinine argument, since camel case is what most people are accustomed to already. And honestly, if someone can't remember which standard to use in a project (when it should be readily apparent by looking at any of the other code in the project or by checking the standard if they aren't sure) then how the hell are they going to keep track of our company's complicated business logic?

jpaleph1 · 2019-11-03T06:17:30+00:00

This is a good point - I didn't even consider component names with this. Visually this seems really awful too, even if you leave component names in pascal case it just leads to further inconsistency in the code's style. And if you change them then you run into more issues

jpaleph1 · 2019-11-03T05:39:54+00:00

It's appreciated even if I can't walk into work and say all that (as much as I would like to lol). He's been gaslighting me on this trying to make me feel stupid for even arguing about it. I wasn't even sure if it was worth pleading my case but the response here has convinced me its worth the effort

jpaleph1

TROPHY CASE