DEV Community

JS Coding Patterns that give you away as a Junior Developer

Matthew Clark on August 31, 2020

Computer programming is somewhere between an art and a science. Your code must match the syntax that the computer expects and understands, but the ...

Read full post

Jason Melton • Sep 1 '20 • Edited

As someone currently looking for junior dev jobs, I definitely have the if else issue. Thanks for showing me a better way.

Paul Patterson • Sep 1 '20

Something that helped me change the way I viewed if statements is using early returns.

Big plus is reducing indentation and easing the cognitive load of the different forks your functions can take.

Jason Melton • Sep 1 '20

Yeah totally. Dealing with a lot of forks stinks. Also this might be obvious, but I remember being excited when I realized you could do if statements on one line, like

if (true) console.log('nice');

For a long time, I always used a block--even for

if (true) { 
    return 
};

Alain Van Hout • Sep 2 '20

Then again, a fair amount of seniors (and depending on the language) will go back to the multiline approach, so that every line does exactly one thing (where the check and the action count as separate things).

𒎏Wii 🏳️‍⚧️ • Sep 2 '20 • Edited

This can be useful for finding errors and analizing test coverage reports as well as making the code easier to visually parse because it's closer to a list of instructions.

Heiker • Sep 1 '20

misuse of functional programming techniques can identify you as a beginner.

No one should judge the experience based on this. If someone misuse an FP technique, the only thing that tells me is that they are learning functional programming.

And just a tiny note here: Array.forEach returns undefined. Keeping it pure wouldn't make any sense. If someone is using it, it's very likely they want to perform a side effect, and that's not bad.

𒎏Wii 🏳️‍⚧️ • Sep 2 '20

I've noticed that the JS community has started using the term "functional" for everything that uses higher-order functions, which is really just a small part of it. Just using map or reduce doesn't make code functional, and forEach is about as un-functional as it gets (It literally is a nop without side effects)

Heiker • Sep 3 '20

I like to think they refer to a "functional style". At the end of the day that's all we can hope for in javascript. We can't even enforce a function to be pure, we can only have them by convention. Sometimes I think is sad that function composition doesn't get as much atention as the array trinity (map, filter, reduce).

𒎏Wii 🏳️‍⚧️ • Sep 4 '20

I wouldn't even say "functional style", rather it's about picking some of specific functional tools that fit the intended domain of ES and ignoring those that don't really add enough value and/or are just not doable in ES.

Function composition, currying, referential transparency... there's lots of concepts that get ignored because they stray too far from how people want to write javascript for the most part.

Allen Miller • Sep 1 '20 • Edited

In my case, and my case only, the older I get the more details I want to see, and when I see very condensed code on one line that usually goes on many, I know that it is very likely written by someone who a few years in programming only.

Terri Fricker • Sep 2 '20

While learning html, css, and javascript, keeping apart the separate functions of each was stressed immensely - markup, style, function. But I'm seeing the value of having some of the style right in the html after working with bootstrap a little bit. It sure made it easier for me to move blocks of code around when I didn't have to chase down css properties. Could you tell me your thinking on that? I'm a ultra-junior developer.

Allen Miller • Sep 2 '20

Here is an advice, my thought only! others will disagree 😊

When someone tells you “Everything must be …” then just ignore the rest of his/her words because they are pointless.

Software development is about comfort, if I put the markup in one file, and the code in another file, will it be more comfortable for me to continue building the App or Website? If yes (for that project and technology), then it is a good idea, if no, then it is a bad idea.

What you normally see in some companies stuff like “Rule nn, all validation must be done on the server side” or some rule like that, and because some big manager wrote that rule, tons of additional code and workarounds are added so the app can follow that rule.

Now think about the next developer who will change the code, will he or she quickly get up to speed and modify it, ideally, the next developer should open Visual Studio, open the project, and be able to debug it with zero additional steps.
Then when he / she looks at the code, should be clear and easy to understand, regardless if the CSS is mixed with the html or JS or not, that absolutely should not matter.

Comfortability is not just the developer, it is the all the people end to end, will the end user love the App? If slow? Unlikely, if instant, oh yes, they will love it, but having the app to run instantly may also mean less comfort on the development side, but unhappy client may also mean no income and that results in no development at all.

I can continue wiring for hours, but at the end, It is just balance 😊

Terri Fricker • Sep 6 '20

Thank you so much for sharing your thoughts! I really appreciate it.

Thomas Semmler • Sep 4 '20

I wish people would stop perpetuating this company-induced hierarchy of developers. This scheme was introduced to find a way to pay less money to capable people. The term "senior" means nothing. We have a responsibility as developers to abolish this arbitrary structures.

This entire phrasing implies that people wouldn't want to be a "junior" developer. Meaning, that all must aspire to not be that. It's a device used by companies to cultivate imposter syndrome to turn them into more productive humans but not pay them in appropriate relation to their skill. People who start out are immediately bombared by the fact that they are something that must immediately aspire to not be any longer.

Many of these patterns are being used by people who call themselves "senior". It doesn't mean anything and it certainly doesn't make those people bad. If "juniors" are using those pattern, then you have failed them as a "senior" in educating them about what other choices they have.

If you read this, if you write code and it works for what you are trying to achieve then that is all that matters. Any pattern in code is subject to "it depends". If it's possible, i'ts not wrong. Wether it is good or appropriate, depends on the context.

Vitaliy • Sep 1 '20

Honestly, unhealthy love for getters/setters makes me sad.
They make any code that employs them look different from what it does - what looks as simple property access/write is actually a function call. Imo, there's no real reason to use them instead of functions, just the matter of taste - a bit shorter syntax and auto bind.

𒎏Wii 🏳️‍⚧️ • Sep 2 '20

Best example is in games where an object has speed + angle or speed_x + speed_y depending on how you want to look at it. It's nice to access either of them as if they were actual variables and not think about how the object stores its velocity vector internally.

That being said, getters/setters go against the "Tell, don't ask" principle. Too much getters/setters are usually a sign that your objects logic might be leaking into different objects, which is very bad in terms of object orientatino.

𒎏Wii 🏳️‍⚧️ • Sep 2 '20

get isSimpson () {
  if (this.lastName === 'Simpson') {
    return true
  }
  return false
}

If anything, I'd say this is worse. Assuming for a moment that it couldn't be simplified further as you do in the article, I think having the else block is preferable because it puts both branches of the decision on the same indentation level and makes it clear that it's either this or that.

If you want to reduce writing and you only have single-statement branches, you could just do

get isSimpson () {
   if (this.lastName === 'Simpson')
      return true
   else
      return false
}

or even put it on 2 lines if the if-condition was a bit shorter.

Kars van Iersel • Sep 1 '20

Hey, you inspired me to write one for CSS coding patterns that give you away as a junior developer!

perpetual . education • Sep 1 '20

These are real things. But - being Jr. is just fine. Getting something working - is always more important than Code Golf.

Alain Van Hout • Sep 2 '20

True enough. But in the long run, having something that's maintainable is at least as (if not more) important as having it fulfil requirements. (Of course, code golf code tends to be poorly maintainable, so I guess we're saying the same thing)

Akihito Mikazuki • Sep 2 '20

This is interesting! I consider myself a junior developer but I don’t use most of these things that would normally give me away as one (like the map thing; that’s usually my go-to)

John Costanzo • Sep 2 '20

I think the if else section is more coding style vs a level of understanding. Writing out a full else if is sometimes preferred as you might come back at some point and want to debug inside that if.

Terri Fricker • Sep 2 '20

Thank you so much! This helps me see how I can make my code more precise, especially using the functions that really describe what is happening - map instead of reduce.