Dumb mistakes and gotchas Code Diary Entries

This is part of the Semicolon&Sons Code Diary - consisting of lessons learned on the job.

• Accurate code but inaccurate labelling is still a bug
• Always check the timestamp when reading logs
• And or precendence
• Anticipate negative numbers in executable strings by wrapping in parens
• Append to file might not add new line
• Be careful of accidentally substituting similarly named variables from an outer scope
• Be mindful of race conditions between long running cron processes
• Be mindful of whether a function mutates a variable or not
• Be sure to empty cyclical data buckets before reusing them
• Boolean or true is always true
• Build way less features
• Cest etc timezones are deprecated
• Check for nonzero exit codes on subprocesses
• Check PATH producing code for double slashes
• CLI flags can be order sensitive
• Code might run with vendor default settings before it runs with your config
• Consider the case of type conversion of nulls
• Do not assume plus operators are available in other languages
• Do not bind variable for the first time in if clauses
• Do not confuse return values with STDOUT
• Do not use empty arrays to mean falsey in logic
• Do not use implicit truthiness and falsiness
• Don't forget to build before manually testing
• Double check autocomplete end of token
• Double check you are in the right file
• Double ux press
• Ensure each entity type was changed properly in project wide search and replace
• Ensure entities are sortable before sorting
• Ensure naming respresents actual object being used
• Establish a time field's timezone before deeper debugging
• Grep and communicate to team before removing DB columns
• If error key not in source check libraries
• If something fails double check you are in the right folder
• Immediately commit added packages
• Just because model code is unavailable does not mean the DB table is not there
• Process killed by OS or overseeingprocess suggests RAM issues
• Proof read changes to prevent accidentally deleting code
• Read the stacktrace instead of guessing
• References to relative file paths in programs break if there are multiple entry point processes running the code
• Remember that AND has a higher precedence than OR
• Remember to submit save or generally finalize data entry
• Set the max tries on a queue system
• Short circuit evaluation sometimes casts to boolean
• Sometimes the bug is with the data not the code
• Sort config settings in alphabetical order
• Sorting records fetched with DB limit does not work
• Start debugging by increasing log level
• Test every generated PATH name and watch out for unintended absolute paths
• Try removing comments when debugging
• Try reordering seemingly symmetric arguments if type errors occur
• Use DB locks to prevent dangerous double executions
• Watch out for binary shadowing
• Watch out for dict like arguments going to wrong function
• Watch out for doubled quotes
• Watch out for function shadowing when a function does not seem to be called
• Watch out for reference vs value variables
• Watch out for shallow merge
• Watch out for typos caused by tripled characters
• Watch out when chaining does not return original object
• When chaining assume each object could be nil unless explicitly ruled out
• When changing on object's structure look for both object and key in question
• When copy pasting files ensure end of file present as manual checksum
• When reading textbooks ensure you are looking at the right figure
• When renaming or moving files be careful not to edit the old copy
• Whenever referencing dependency code ask if it is available in all environments
• Write down instructions especially vendor names
• Wrong number of iterations means whole function may have been wrongly called multiple times