One of the favorite classes that I took in college was an introductory course to Chinese philosophy.
From time to time, I found one or two passages from The Analects that I could apply to my computer science major.
One of my favorites is passage 13:3:
Tzu-lu said, "The ruler of Wei is waiting for you to serve in his administration. What will be your first measure?" Confucius said, "It will certainly be the rectification of names." Tzu-lu said, "Is that so? You are wide of the mark. Why should there be such a rectification?" Confucius said, "Yu! How uncultivated you are! With regard to what he does not know, the superior man should maintain an attitude of reserve. If names are not rectified, then language will not be in accord with truth, then things cannot be accomplished. If things cannot be accomplished, then ceremonies and music will not flourish...."
"Therefore, the superior man will give only names that can be described in speech and say only what can be carried out in practice."
To me, this applies to software engineering in the naming of classes, methods, properties, variables, and so on. As McConnell writes in Code Complete,
The smaller part of the job of programming is writing a program so that the computer can read it; the larger part is writing it so that other humans can read it. let [the reader] use their brain cells to understand the larger question of how your code works rather than the syntactic details of a specific expression. You write readable code because it helps other people to read your code.
Indeed, sensible naming is a big part of this idea of legibility. What I dig about Visual Studio 2008 is that the installed documentation includes excerpts from Framework Design Guidelines by Cwalina and Abrams which aims to include some of the key naming and design best practices into the core literature on the .NET Framework. It's a necessary and needed move to help forward the education of the legion of .NET developers who continue to perpetrate terrible naming practices carried over from VB.
I mean seriously: if I have to read one more method name as a noun (or a property as a verb or a class as a verb), I'll just have to start researching a way to let me reach across the Internet and punch someone in the face -- nothing ruins my morning quite like finding a new class in source control named as a verb. I'm also midly irritated when developers choose unconventional names for object types. For example, the use of "Checker" as opposed to "Validator" -- ugh!
Admittedly, some artifacts are just really hard to name. But in such cases, proper naming is probably even more important since if it's hard for the writer of the code to come up with a proper name, the wrong name will make the artifact even harder to understand for secondary readers. There have been times where I've spent days trying to come up with a suitable name for a class (I'll name it, but I'll continue to mull it over through restless nights (true story) and refactor it once I do come up with a suitable name) since the last thing I want to do is to give something a cryptic, hard to understand name.
One of the easiest ways around this is to spend some time digging around the SDK and look for similar patterns in naming and see how the .NET framework designers structured their class and member names. I also think that Cwalina and Abrams' Framework Design Guideline is a stalwart component of any .NET developer's library.
So the next time you're about to write a class name or create a new member, just remember, "If names are not rectified, then language will not be in accord with truth, then things cannot be accomplished. If things cannot be accomplished, then ceremonies and music will not flourish". I mean, who doesn't want their project to end with ceremonies and music