|
|
(One intermediate revision by the same user not shown) |
Line 1: |
Line 1: |
| | {{programming}} |
| | |
| ==People like acronyms== | | ==People like acronyms== |
|
| |
|
Line 9: |
Line 11: |
|
| |
|
|
| |
|
| OO classes are good to also avoid repeating state management. {{comment|(if not as automatically good at encapsulation as we like to pretend they are, but that's practice to be a very real problem in, not nice abstracted acronyms)}} | | OO classes are sometimes good to avoid code repeating code and/or repeating state management. |
| | {{comment|(though not as always also good at [[encapsulation]] as we like to pretend they are)}} |
|
| |
|
|
| |
|
Latest revision as of 13:56, 9 January 2024
Some fragmented programming-related notes, not meant as introduction or tutorial
Data: Numbers in computers ·· Computer dates and times ·· Data structures
Wider abstractions: Programming language typology and glossary · Generics and templating ·· Some abstractions around programming · · Computational complexity theory notes · Synchronous, asynchronous · First-class citizen
Syntaxy abstractions: Constness · Memory aliasing · Binding, assignment, and such · Closures · Context manager · Garbage collection
Sharing stuff: Communicated state and calls · Locking, data versioning, concurrency, and larger-scale computing notes
Language specific: Python notes ·· C and C++ notes · Compiling and linking ·· Lua notes
Teams and products: Programming in teams, working on larger systems, keeping code healthy · Benchmarking, performance testing, load testing, stress testing, etc. · Maintainability
More applied notes: Optimized number crunching · File polling, event notification · Webdev · GUI toolkit notes
Mechanics of duct taping software together: Automation, remote management, configuration management · Build tool notes · Installers
|
People like acronyms
DRY
Don't Repeat Yourself.
Functions are good to avoid repeating code.
OO classes are sometimes good to avoid code repeating code and/or repeating state management.
YAGNI
You Aren't Gonna Need It basically says "don't add functionality until you actually need it"
Can apply to design as well as code.
SOLID
GRASP
On premature optimization