Dear diary
In the last days of 2018 I got pulled into a style war that had apparently been waged under covers for a month.
Personae:
We really started out well
I'll do my best
I know JS!
I'll just get my tickets done
What is this? (me)
It went like this:
: Now that we have the visual design done, can start coding as everybody else is busy.
: I don't know frontend JS but I have domain knowledge.
weeks pass
: I wrote this code.
: Now can take over to implement the rest of the features
: This code of has no style! I'll use my own style because it's the best.
weeks pass
: Hey I can't really work all that much coming months. Didn't see that coming or anything.
: Let's add to the team!
weeks pass
: Hey please review these pull requests for me
: What the fuck ? in every file you touch you change all comments to use /*...*/
instead of // ...
: Progress! Use the .editorconfig
: I'm just going to ignore any of that.
: Hey your code doesn't follow the style!
: Your's doesn't either!
weeks pass
: What about my pull-requests?
: Hey I don't want to review commits that mix style changes with code changes!
: Say can you help me with some code-reviews?
: Sure. What is it?
: Both and work on this project, but refuses to do code-reviews with . They're piling up.
: I'll do a functional review and merge regardless of code-style to get things moving again.
: Fine by me, we'll do the code-style discussion next year.
Now at this point, I merge a few pull-requests of which are written in a style of his own devising. Company policy for Javascript would be AirBnB. But hey, discussion delayed. (Will probably just use an autoformatter in the future.)
Then I get to the pull-requests of .
: Say why do you write your local variables in ALL_CAPS?
: Ah you see these are constants. You probably don't know const
yet. It's a new feature.
: I know what const
is, but why are the names ALL_CAPS?
: Because constants are written in ALL_CAPS, you know that don't you!?
: Well, there's the convention to write global names in ALL_CAPS to differentiate them from local variables
: Yes see? Those are constants too!
: Well but these local variables are not constants!
: Are too! Because I used const
to declare them. It really helps preventing errors! You really should learn some modern JS!
: I'm all for the use of const
but I have a hard time reading this code...
: I get it you don't have much experience with JS
: No I mean that from my experience ALL_CAPS is used for globals and I get really confused reading this code
: You'll get used to how modern JS is written
: Nobody except you uses this style!
: How do you know? You're just lacking experience in the field.
: I've never seen code written like this...
: ...because you don't have the experience
: Forget it. I'll ignore code-style now so we'll have this discussion some other day. I'm also troubled by this long method.
: This is how JS is written
: It interleaves widget configuration data with network requests and their callbacks.
: Not my fault if you can't follow modern Javascript code
: It's over 200 lines and nests for more than ten levels!!
: That's because it uses closures!
: That's not a reason!
: Look here I define the callback to this request as a closure. Easy!
: Extract it and put it somewhere else!
: But then I don't have access to the local constants!
: All these variables in scope makes it really hard to follow the logic.
: It's constants! Get used to it! That's how JS is written now!
: And all this chart configuration data you can build in another function.
: But I need access to local constants! You really don't know how closures work do you?
: Pass them as parameters nice and explicit
: It's better to have them in local scope for speed
: Sigh. Why do you use timeouts to schedule network requests here?
: Because the chart library gets confused when data is loaded in parallel
: But then if one network request is delayed it will still get confused?
: Well no, I made the timeout really long, see here? 1.5 seconds!
: So it's slow for everybody...
: there's no other way
: ..and still it'll break if the responses are delayed for long enough
: But that's unlikely
: Unacceptable
: If only we could use promises!
: What do promises have to do with it?
: So we wouldn't get back the responses in parallel.
: JS doesn't have parallel execution
: Does too!
: No I mean the browser VM doesn't have parallel execution
: Read up! Promises are the future!
: What happens if the user interacts with the interface while it's loading?
: What should happen?
: I mean, wouldn't the requests interleave then?
: That's why this code is in onload
: Not after the first request, see if I do this while it's loading?
: Yeah it breaks, you should wait till it's loaded properly.
: Unacceptable
: We could disable the interface till it's all loaded but that's a lot of work
: Hacky but that would work.
: Ah if only we could use promises, would fix it instantly
: No it wouldn't.
: You don't know promises
Fucking insufferable type! I ended up refactoring and then fixing his shit.