6 ms·

There are only two hard problems in Computer Science: cache invalidation and naming things. -- Phil Karlton There should be a short list of words never to app

There are only two hard problems in Computer Science: cache invalidation and naming things. -- Phil Karlton There should be a short list of words never to appear in names. "Manager" is certainly one. I nominate "Handler" as another.

matwood 14y ago
From the Android SDK :) http://developer.android.com/reference/android/os/Handler.html http://developer.android.com/reference/android/os/Handler.ht...
- dack 14y ago
  Man, as much as I like the idea of Android, the SDK trips me up so often!
bleair 14y ago
There are only 2 hard problems in computer science, caching, and naming things, and off by one errors
- Evbn 14y ago
  Unambiguous syntax is also a hard problem, it now appears.
nailer 14y ago
More meaningless words: - system. Everything is a system. - data. Everything that isn't executable is data.
cpeterso 14y ago
The class name modifier that irks me is "Base", as in BaseWidget or ConnectionBase. Just call them a Widget or Connection! :)
- yen223 14y ago
  BaseWidget is useful when it's an abstract class, to differentiate it from the actual implementations WidgetA and WidgetB.
  - cpeterso 14y ago
    Wouldn't a "Widget" abstract class name also be differentiated from "WidgetA" and "WidgetB" implementations? Then APIs could take parameters of type Widget instead of type BaseWidget. "Widget" is a shorter, cleaner name and avoids documenting implementation details like names such as "BaseWidget" or "AbstractWidget".
    - sha90 14y ago
      There are certain ... linguistic... reasons why Base appears in class names. It's important to understand the subtlety. In certain languages, especially those with packages or namespaces, you'll likely have a namespace Foo::Bar::Widgets where you put your WhateverWidgetWhatever classes. The package foo.bar.widgets.widget, or namespace Foo::Bar::Widgets::Widget, can look weird to some; it's also longer / less predictable, so you could potentially see them simply be called Foo::Bar::Widget::Base, which avoids naming duplication, and allows developers to not have to worry about plural/singular names.
    - dack 14y ago
      Usually, I want to make the name of my interface the cleanest possible name. In that case, my interface would be named "Widget". Then, if it makes sense, I might have a partial implementation that works for many cases - I would probably call that WidgetBase. Actual implementations of the widget would try to have a name related to what makes them different than the others - maybe Button, TextBox, etc. Those implementations might inherit from WidgetBase if it makes sense, or just implement the interface. At any rate, WidgetBase is only ever referenced by subclasses - the users of the widget code would either depend on "Button" or "TextBox" specficially, or the "Widget" interface for more generic handling. WidgetBase is really just there for convenience, and you could remove it if it turns out not to be as useful as you thought.
MartinCron 14y ago
I personally don't like "Helper". Shouldn't every class be helpful?
deleted 14y ago
[deleted]
Jare 14y ago
Naming things is only hard if you are trying to be consistent across a large systems, or hoping that names will replace documentation and assumptions. If you are going to ban names, I nominate the entire index of the GoF book: Factory, Singleton, Command, Proxy, etc. all sort of convey an idea of the kind of stuff they probably do, but nothing truly precise about the details. Or I can just accept a rough meaning of the word, name my classes / modules / variables / etc reasonably and then rely on a coherent approach to design and documentation to provide with the details. - XXXManager: owns the lifetime of objects of class XXX and the relationships between them. - XXXHandler: responds to events relating to XXX. - XXXFactory: creates instances of the polymorphic type XXX - etc.

matwood 14y ago

From the Android SDK :) http://developer.android.com/reference/android/os/Handler.html http://developer.android.com/reference/android/os/Handler.ht...

dack 14y ago
Man, as much as I like the idea of Android, the SDK trips me up so often!

bleair 14y ago

There are only 2 hard problems in computer science, caching, and naming things, and off by one errors

Evbn 14y ago
Unambiguous syntax is also a hard problem, it now appears.

nailer 14y ago

More meaningless words: - system. Everything is a system. - data. Everything that isn't executable is data.

cpeterso 14y ago

The class name modifier that irks me is "Base", as in BaseWidget or ConnectionBase. Just call them a Widget or Connection! :)

yen223 14y ago
BaseWidget is useful when it's an abstract class, to differentiate it from the actual implementations WidgetA and WidgetB.
- cpeterso 14y ago
  Wouldn't a "Widget" abstract class name also be differentiated from "WidgetA" and "WidgetB" implementations? Then APIs could take parameters of type Widget instead of type BaseWidget. "Widget" is a shorter, cleaner name and avoids documenting implementation details like names such as "BaseWidget" or "AbstractWidget".
  - sha90 14y ago
    There are certain ... linguistic... reasons why Base appears in class names. It's important to understand the subtlety. In certain languages, especially those with packages or namespaces, you'll likely have a namespace Foo::Bar::Widgets where you put your WhateverWidgetWhatever classes. The package foo.bar.widgets.widget, or namespace Foo::Bar::Widgets::Widget, can look weird to some; it's also longer / less predictable, so you could potentially see them simply be called Foo::Bar::Widget::Base, which avoids naming duplication, and allows developers to not have to worry about plural/singular names.
  - dack 14y ago
    Usually, I want to make the name of my interface the cleanest possible name. In that case, my interface would be named "Widget". Then, if it makes sense, I might have a partial implementation that works for many cases - I would probably call that WidgetBase. Actual implementations of the widget would try to have a name related to what makes them different than the others - maybe Button, TextBox, etc. Those implementations might inherit from WidgetBase if it makes sense, or just implement the interface. At any rate, WidgetBase is only ever referenced by subclasses - the users of the widget code would either depend on "Button" or "TextBox" specficially, or the "Widget" interface for more generic handling. WidgetBase is really just there for convenience, and you could remove it if it turns out not to be as useful as you thought.

MartinCron 14y ago

I personally don't like "Helper". Shouldn't every class be helpful?

deleted 14y ago

[deleted]

Jare 14y ago

Naming things is only hard if you are trying to be consistent across a large systems, or hoping that names will replace documentation and assumptions. If you are going to ban names, I nominate the entire index of the GoF book: Factory, Singleton, Command, Proxy, etc. all sort of convey an idea of the kind of stuff they probably do, but nothing truly precise about the details. Or I can just accept a rough meaning of the word, name my classes / modules / variables / etc reasonably and then rely on a coherent approach to design and documentation to provide with the details. - XXXManager: owns the lifetime of objects of class XXX and the relationships between them. - XXXHandler: responds to events relating to XXX. - XXXFactory: creates instances of the polymorphic type XXX - etc.