Computer programming is somewhere between an art and a science. Your code must match the syntax that the computer expects and understands, but the ...
For further actions, you may consider blocking this person and/or reporting abuse
As someone currently looking for junior dev jobs, I definitely have the
if elseissue. Thanks for showing me a better way.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.
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
For a long time, I always used a block--even for
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).
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.
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.forEachreturnsundefined. 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.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
maporreducedoesn't make code functional, andforEachis about as un-functional as it gets (It literally is a nop without side effects)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).
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.
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.
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.
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 😊
Thank you so much for sharing your thoughts! I really appreciate it.
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.
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
or even put it on 2 lines if the
if-condition was a bit shorter.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.
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.
Hey, you inspired me to write one for CSS coding patterns that give you away as a junior developer!
These are real things. But - being Jr. is just fine. Getting something working - is always more important than Code Golf.
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)
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.
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)
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.