david loves coding

a notebook

1 note

Class Naming: Tips & Tricks

Class, variable, and other namings are one of the most important things a programmer has to deal with when writing code. Not only good names will allow others to better understand your code, but also code reusability will benefit from it.

This is a compilation of recommendations for class naming:


[SO] From Implementation Patterns by Kent Beck:

  • Simple Superclass Name: Pick strong metaphors for the computation the class does.
  • Qualified Subclass Name: If a subclass is the root of its own hierarchy, use a simple class; if not, you can use more words to be more expressive at the cost of being less concise.
  • Interfaces: Name them following the two previous points, if they are abstract interfaces. This will lead to use the best names for interfaces leaving you with somewhat strange names for subclases (File → ActualFile, ConcreteFile, FileImpl). Nevertheless, communicating if an object is abstract or concrete is usually important.

[SO] If you adhere to the Single Responsibility Principle (SRP), it should be easy to come up with good names. If a class is hard to name or explain then it’s probably not following the SRP. A class name should instantly communicate what the class is. Good names drive good designs.


Ottinger’s Rules for Variable and Class Naming (also in Clean Code’s second chapter):

  • Use intention revealing names
  • Avoid disinformation:
    • Don’t name something a list if it’s not really a list.
    • Beware of using names which vary in small ways.
  • Make meaningful distinctions:
    • Avoid noise words (Product vs ProductData vs ProductInfo)
  • Use pronounceable names
  • Use searchable names
  • Avoid encodings (e.g. String m_psz;)
  • Avoid mental mapping: Strive for problem domaing terms and solution domain terms.
  • Use noun and verb phrases for classes:
    • Accessors can have a noun name too.
    • Mutatos must not have a noun name, because they are causing something to happen.
  • Pick one word for one abstract concept and stick with it
  • Try to never use the same word for two purposes
  • Use rich name sources
    • Use solution domain names (when working in a low-level of abstraction; this includes algorithm names, data structures, CS terms, pattern names, etc.)
    • Use problem domain names (When there is no programming name for what you’re doing, use the name from the problem domain)
  • Add meaninful context
  • Don’t add gratuitous context (like prefixing every class with the first letters of the application name)

Interesting pages from c2 wiki related to naming:

Filed under programming naming

0 notes

The Laws Of Software Design

  1. The purpose of software is to help people.
  2. The Equation of Software Design
  3. The Law of Change: The longer your program exists, the more probable it is that any piece of it will have to change.
  4. The Law of Defect Probability: The chance of introducing a defect into your program is proportional to the size of the changes you make to it.
  5. The Law of Simplicity: The ease of maintenance of any piece of software is proportional to the simplicity of its individual pieces.
  6. The Law of Testing: The degree to which you know how your software behaves is the degree to which you have accurately tested.

Book: Code Simplicity via genbetadev

Filed under software development books

0 notes

Typical main phases of UX projects

  • The research phase is where you immerse yourself in the project to get the background you’ll need to make design decisions later in the project. During this phase you will try to learn as much about your client’s business, objectives, users and competitors as possible.
  • The design phase is where you work out how what you are designing will work and how it will fit together. This phase will define its scope, its features and functionality and how it behaves.
  • The validation phase is where you identify whether what you came up with in the design phase actually works with its intended audience. This phase is typically followed by further rounds of design and testing to solve the problems you inevitably find when you test with users.

Source: Smashing Magazine - Effectively Planning UX Design Projects

Filed under user-experience