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.
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.