Write down exactly what your function does
Don’t hesitate to write long function names to have a clean code: write “getProductById”, “sendEmailToUsersWhoHaveNotConfirmedYet”, “getSortedListOfKeywordsForProduct”...
DEAR READER
Not today Justin

⁂

JVL
No title available
trying on a metaphor
Sade Olutola
will byers stan first human second
Xuebing Du
Stranger Things
Lint Roller? I Barely Know Her
wallacepolsom
occasionally subtle

Janaina Medeiros
Misplaced Lens Cap

if i look back, i am lost
2025 on Tumblr: Trends That Defined the Year
noise dept.

No title available
sheepfilms

seen from South Africa

seen from Türkiye
seen from Canada
seen from United States
seen from Sweden

seen from Türkiye
seen from Malaysia

seen from Australia

seen from Türkiye

seen from United States

seen from T1

seen from Canada
seen from United States

seen from United Kingdom

seen from Türkiye

seen from Spain
seen from United Kingdom
seen from Germany
seen from United States
seen from Türkiye
@cleanprogramming-blog
Write down exactly what your function does
Don’t hesitate to write long function names to have a clean code: write “getProductById”, “sendEmailToUsersWhoHaveNotConfirmedYet”, “getSortedListOfKeywordsForProduct”...
Append types and/or units for your variables
The names of your variables should reflect what they contain and how it can be used; if the name itself isn’t unambiguous, add a suffix to fully explain what’s in there.
You should prefer suffixes because the first letters of your variables should contains the specifics of the variable in order to use your fav IDE autocompletion.
For example, use “keyword” for a string, “keywords” or “keywordsList” for a list of strings (instead of “k”, “listKeywords”...). You can write “quantity” because it’s obviously a positive integer, but you should write “angleInDegrees” instead of “angle”.
Maximum 2 arguments per method
Except some peculiar cases, you should’t have more than 2 defined parameters for each of your functions; this should improve the legibility and usability of your code, as well as simplify tests.
Nested conditional statements - the hard way
switch (false) case condition1: manageErrorWithCondition1NotVerified(); break; case condition2: manageErrorWithCondition2NotVerified(); break; case condition3: manageErrorWithCondition3NotVerified(); break; ... default: codeWhenAllConditionsAreVerified();
Don’t nest loops and conditional statements more than once
If you have more than 2 levels of indenting, your code starts to become hard to read. You should use refactoring to make smaller portions of code.
Use constants names instead of static values
Replace:
if (time > 3600)
with:
if (time > AN_HOUR_IN_SECONDS)
Replace comments with code
Replace:
// Do something command1 command2 command3
with:
doSomething()
Nested if
if (!condition1) manageError() break_or_return
block1
if (!condition2) manageError() break_or_return
block2
if (!condition3)...