Anyone else find naming classes and methods one of the most difficult parts in programming? [closed]

Answer 1

Don't forget design patterns (not just the GoF ones) are a good way of providing a common vocabulary and their names should be used whenever one fits the situation. That will even help newcomers that are familiar with the nomenclature to quickly understand the architecture. Is this class you're working on supposed to act like a Proxy, or even a Façade ?

Answer 2

For me I don't care how long a method or class name is as long as its descriptive and in the correct library. Long gone are the days where you should remember where each part of the API resides.

Intelisense exists for all major languages. Therefore when using a 3rd party API I like to use its intelisense for the documentation as opposed to using the 'actual' documentation.

With that in mind I am fine to create a method name such as

StevesPostOnMethodNamesBeingLongOrShort

Long - but so what. Who doesnt use 24inch screens these days!

Answer 3

Shouldn't the vendor documentation be the object? I mean, that one is tangible, and not just as some anthropomorphization of a part of your program. So, you might have a VendorDocumentation class with a constructor that fetches the information. I think that if a class name contains a verb, often something has gone wrong.

Answer 4

If the name would explain itself to a lay programmer then there's probably no need to change it.

Answer 5

I find I have the most trouble in local variables. For example, I want to create an object of type DocGetter. So I know it's a DocGetter. Why do I need to give it another name? I usually end up giving it a name like dg (for DocGetter) or temp or something equally nondescriptive.

Answer 6

Nope, debugging is the most difficult thing thing for me! :-)