When we write code, we often find ourselves pressured to work faster, sacrificing the quality of the product.
Something We can do as Developers:
Clockmakers leave subtle marks to help guide the next person who has to work on that clock - we developers should do the same, it makes everything better for the next person to work on the code, even when that person is you!
Software Engineering is the field I know best about, and this will probably make little sense to people who are not in it. Specifically FE people in particular might appreciate this post most, as TS is my language de jour.
Double Bang:
Using `!!` at the front of a line, such as:
`const foo = ((thisThis || thatThing ) && (theOther thing && thatOtheThing))`
If you instead write:
`const foo = !!((thisThis || thatThing ) && (theOther thing && thatOtheThing))`
I IMMEDIATELY know that this is going to be a `boolean` with the value of whatever this check returns. Without it, I need to read the entire thing, then I see there is nothing else, say turnary, it’s just straight this.
Ternaries:
Don’t use double (or more) turnaries!! They suck, they are hard to mentally process, and waaaaay too many times I have found bugs specifically because they are bad.
Single ones are totally fine. Double or higher, you need to break it up.
Single ones are fine. Double or higher, you need to break it up.
Again, it sacrifices having code in-line, and instead makes you move things to a function…That I hope you named after what it does! Something something something 2 hardest problems…
IF and Other Statements:
Well, there is too much here to talk about, so I will address the first ones in my mind.
Curly brackets – always use them, unless you can put everything on one line:
“`
if(foo) return bar;
FINE
if (foo) {
Do something!
}
FINE
If (foo)
Do something
BADDDD! – people will add stuff and not realize there are no curly braces, so their thing after won’t actually fire. Putting everything on one line is a Signpost that tells us “there are no braces, this is a stand-alone statement.
Functions:
These can be written several ways!
- `const foo = function(x) {return ‘But Why!?}`
- `function thingyImDoing(…)`
- `const bar = () => {return ‘But Why?’}`
Obviously there are more, but these are the basics.
These all do different things. There are more, but these are the ones most use, and therefore are the ones we should cover.
Do you know the difference?
#2 Is what is known as a “function expression” – these are special.
When you use #2 for function is always there (see: function scoping)
I use this option specifically when I have a lot of code, I take advantage of “hoisting” and put these at the bottom, because I am satisfied with name “removePersonFromEmail()” to be a Signpost that tells me what is happening here. It also preservers the this binding – not super important these days, but you should be aware especially if you are using jQuery or similar libraries.
#3 is Arrow Function (IE: “Fat Arrow”) – all the cool kids write them this way these days. You should think about it first though, can you introduce a Signpost? Mostly NOT using them IS the signpost. If I see the `function` keyword I know I need to be aware that there is code at the bottom of the file that I need to look at for a more holistic view.
#1 Signpost that tells me you suck…why are you even doing this? Can it actually make sense?Generally not. …It is _I think_ an unnamed function expression – actually, I kind of want to know what happens – it is unnamed, so the definition might be hoisted in an unusable way? But since it is a const, it would hit the Temporal Dead Zone…Ok, the reason you would use it is because you want to preserve the this binding but don’t need hoisting? That’s my best guess on what would happen. THAT SIGNPOST SUCKS!
Const and let:
These are obviously Signposts – they tell you if a var will change or not. If it is a `const` it will always be that value – if it is `let` it could be something totally different….Except blah blah blah.