|
|
|
|
|
|
by FeatureRush
3280 days ago
|
|
|
Some anonymous comment on the Internet told me once that the 'naming things' bit was about some problem in distributed systems, I guess it was a lie then? Good slides, not only the advice, but also the steady peace of delivery, the programming ~ writing theme and overall structure. I misses advice about never naming classes with words ending in -or and -er, is this still a thing? In the context of functional languages one letter variables are often sold as a feature, where hindrance of cryptic names is overweighted by benefits of being able easier bring smaller amount of text into the mind of the programmer (may require some practice). And personally I also recently observed that this abstract, mathematic notation helps me focus on the very abstract and mathematic core of some definitions in Haskell. It's good to use word "Car" when dealing with cars, but when inside of morphism-monad-whatever 1-line function definition "a" is OK, who knows what datatype will implement it? One advice that helped me about naming things is not to have things to name in the first place. Very often I used to create lots of variables representing intermediate and not really interesting steps of computation, resulting in horrible names like file_content, validated_content, parsed_content and so on... Just thinking first about how to structure things will prevent many of risky naming situations from even appearing. |
|
|
The problem with that idea is that it clashes with the OOP notion typical in languages like C++, Java, C# and so on. (Though it does make dependency injection and persistence of the state easier.)
Plus some names like "allocator" or "garbage collector" are ingrained in standard.
(FYI the state for an allocator could be a freelist, for GC could be a graph.)