This is a weekly roundup of awesome DEV comments that you may have missed. You are welcome and encouraged to boost posts and comments yourself using the #bestofdev tag.
Replying to What's the best career advice you can give in ten words or less? @damcosset
hit on something you should keep squarely in mind as you begin your career:
Don't worry, nobody knows what they are doing.
In What habit do many senior engineers have that juniors should try to avoid adopting?, @sunnysingh
remarks on the temptations of being clever:
Avoiding clever code.
You feel smart writing clever code, and you may even justify it by saying it's less code. However, code should be explicit and thus be understandable by everyone. Even if that means writing slightly more code.
Before working on DEV, I never had an appreciation for the importance of naming things. Working alongside @ben
has been very instructive in this regard. I enjoyed reading @gypsydave5
's reply to Do you have a process for naming things?:
Explicit? No. But here are my rules of thumb.
1. Don't try and name things too eagerly. Naming is, if anything, the beginning of abstraction. As soon as something gets a name, it brings in mental baggage from everyone that reads it. Bad names lead to bad abstractions everywhere else.
1.1. When you're writing software, you probably have no idea what you're doing. You don't understand what you're trying to build, what the right shape, organization, style of code is for the domain you're trying to work with. Bad names are usually evidence of someone misunderstanding what they were building at an earlier time in the development process. But then the name stuck because everyone was using it... so the bad names proliferate.
1.2. So if anything, prefer a screamingly awful name that completely misses the mark than one that is full of baggage and opinion.
Thingy is just fine by me.
2. If you put
I in front of your interface names I will shout at you in an unkind way. This is 2019 - you don't need to use Hungarian Notation to express the type of a variable. If anything, the interface should name the general case and the implementation should name the concrete.
Database could be the interface,
PostgreDatabase could be the concrete type.
2.1. If your interfaces are describing behaviour (á la Go), use an agent noun based on the verb that captures the behaviour:
4. Name length should be proportional to how long the variable will live, and how it's scoped. If it's just the iteration counter,
i is fine. But if it is exported then I want to see a bit of verbosity.
4.1. This matters less with typed languages; I'm pretty confident I know what
db is if it's declared as
Database db = ...
5.1. Name methods (and namespaced functions) fluently, taking into account the (likely) receiver name;
6. Stop trying so damn hard - you're probably giving it the wrong name anyway so come back to it tomorrow when you've had some time to think.
Edit: removed point 3 about screaming snake case for constants as I've been convinced it's just pointless
Edit: just want to point out that I pulled these out of the top of my head so I'd hate it if anyone quoted them back to me in a code review in six month's time
What is that one tool/stack/framework that you have no interest with despite the popularity? @cjbrooks12
talks about their lack of interest in one of the most popular frameworks out there:
provides a great list of resources in response to Web Developers and Designers, where do you get your raw materials from?:
Logodust for logos if I need something quickly for prototyping.
Undraw for open source svg illustrations
templated.co for free templates/inspiration
UIGoodies also has quite a few decent things on there.
cssfx for quick copy-paste css animations
See you next week for more great comments ✌