| > While I basically use if/else, he uses ternary operators. I write functions by hand, the uses arrow functions and symbols I can hardly understand. What you are describing is commonly known as ES6 or ES2015 syntax. The language got some features at that time that solve gotchas related to using JS and arrow functions are a great example. These features make JavaScript easier to work with if you use them, and learning the most important ones doesn't take more than a day. https://www.boardinfinity.com/blog/top-10-features-of-es6/ After 20165, they only released like 2 features per year, and most of those haven't had the same adoption. Arrow functions are a great example, as they don't have their own `this` and it makes the `this` keyword work how you think it should. > ternary operators vs if/else Sometimes new features make sense in a certain context. If/else makes sense if your code has actual branching, but if the assignment of a single variable is all you need to branch for, ternaries are great. ```
// classic JS
let variable; if (someCondition) {
variable = 'foo';
} else {
variable = 'bar';
} // with ternary const variable = someCondition ? 'foo' : 'bar';
``` > We do not have the time to code review his projects. That's crazy. Ternaries are also a great example of a feature that can be abused. As conditions get more complex, ternaries become more opaque and are a worse choice. More concise code isn't necessarily better. This can be true for a lot of JS. Fancier code isn't better if the rest of the team can't understand it, and if you don't have a review system, you can't blame him for writing in his own accent and you not being able to understand. Developers on a team need oversight. I catch bugs my teammates write, and they do for me too. If you can't understand it when the PR is made, you're not going to understand it later. So my answer to you is to try to start doing code review. Reading code is important, and a PR should be focused enough that you can track what a feature or bugfix is actually doing. If you can't, you should be speaking up. > Also, he should not be my teacher. Why not? What dev wants their teammates to struggle? I love helping more jr developers, and I've never had someone on any team bristle when I asked them to help me. |