/Naming

Against Names

- Steve Klabnik tl;dr: “I am not actually claiming we should stop giving things names. But I have had at least two situations recently where I previously found names to be kinda critical, and then I changed to systems which didn’t use names, and I think it improved the situation.” Steve shares examples. 

featured in #542

Against Names

- Steve Klabnik tl;dr: “I am not actually claiming we should stop giving things names. But I have had at least two situations recently where I previously found names to be kinda critical, and then I changed to systems which didn’t use names, and I think it improved the situation.” Steve shares examples. 

featured in #541

Falsehoods Programmers Believe About Names

- Patrick McKenzie tl;dr: As a public service, I’m going to list assumptions your systems probably make about names. All of these assumptions are wrong. Try to make less of them next time you write a system which touches names. (1) People have exactly one canonical full name. (2) People have exactly one full name which they go by. (3) People have, at this point in time, exactly one canonical full name. (4) People have, at this point in time, one full name which they go by. (5) People have exactly N names, for any value of N.

featured in #523

Prefer Noun-Adjective Naming

- Kyle Shevlin tl;dr: Kyle uses noun-adjective naming for components, e.g., StreamCreated instead of CreatedStream. This keeps related components together alphabetically in directories and makes them easier to search for. It's a small change but can lead to better organization in a codebase.

featured in #517

When To Use Cute Names Or Descriptive Names

- Nicole Tietz-Sokolskaya tl;dr: If a name is hard to change and the code is likely to evolve, use a creative, "cute" name. A descriptive name becomes a liability if it can't keep up with changes. If a name is easy to change, use a descriptive and unambiguous name, even if it gets verbose. Verbosity signals when something needs refactoring. Nicole shares high-level thoughts around naming.

featured in #504

What’s In A Name?

- Adam Raider tl;dr: Tips for naming from Google: (1) Spend time considering names — it’s worth it, especially APIs. (2) Describe behavior. (3) Reveal intent with a contextually appropriate level of abstraction. (4) Prefer unique, precise names. (5) Balance clarity and conciseness—use abbreviations with care. (6) Avoid repetition and filler words. (7) Software changes —names should, too. 

featured in #501

On The Importance Of Naming In Programming

- Martin Sosic tl;dr: “The best advice is maybe not to give a name, but instead to find out a name. You shouldn’t be making up an original name, as if you are naming a pet or a child; you are instead looking for the essence of the thing you are naming, and the name should present itself based on it. If you don’t like the name you discovered, it means you don’t like the thing you are naming, and you should change that thing by improving the design of your code.” Martin gives a couple of examples.

featured in #457

Names Should Be As Short As Possible While Still Being Clear

- Ben Hoyt tl;dr: “Some developers do use names that are too short. However, I think the more common mistake is using names that are overly long.” Ben illustrates this point, and the importance of naming in context, using examples.

featured in #430

Naming Conventions In Programming – A Review Of Scientific Literature

- Iwo Herka tl;dr: This article is divided into 2 chapters: (1) “Introduction to naming in programming”: A review of scientific literature present on the topic to deepen your understanding of the current body of knowledge on naming things. (2) “Guidelines for naming conventions in programming”: recommendations to improve your skills in choosing thoughtful class, function or variable names.

featured in #397

Taming Names In Software Development

- Joseph Glass tl;dr: "Balancing these opposing principles is what makes good naming so hard. The amount of knowledge conveyed in a single word is what makes good naming so powerful. The exact balance will depend on the size of the codebase and developer team, the domain complexity, frequency of use and many other factors."

featured in #374