Solidity Basics: Your First Lines of Code — Real-world failure modes
Know how a Solidity file is structured.
Accidental exposureLeaving a function public when it should be internal can brick a system or leak funds. Public state getters can reveal assumptions you did not intend integrators to rely on.
The root problem with conventional currency is all the trust that’s required to make it work.
Storage mishapsPassing storage pointers around or forgetting memory/calldata can mutate shared arrays/structs. Bugs often look like "state changed elsewhere" when it was a mistaken reference.
Loose pragmasFloating or wide pragmas let CI pick newer compilers with different behaviors or security fixes you did not test. Teams have shipped code that failed because a new compiler tightened checks.
Silent defaultsFunctions without mutability keywords can be misunderstood by reviewers and tools. Forgetting payable can block deposits; forgetting view can mislead about gas costs.
- Public by accident:Functions default to public in older examples; always set visibility.
- Storage vs memory:Unintended mutations when using storage references in helper functions.
- Missing payable:Functions meant to receive ETH revert because payable was omitted.
- Wide pragma:Builds pick a newer compiler than audits covered; behavior or warnings change.
- Unchecked getters:Relying on auto-generated getters without considering gas or reentrancy in external calls.
- Shadowed variables:Confusing state vs local variables leading to wrong assignments.