I'm currently working on a site which went through god knows how many developers' hands. One of the things I don't like about it is the way every table in the database has the prefix "tbl_" and every field "fld_".
I've started work on a new feature and I'm faced with the following problem: should my new tables continue with the old convention, or not?
I guess I should, but I feel stupid doing it :)
I would keep the same convention.. Regardless of if it's bad or not at least it would be consistent. And consistency will be very important to the next developer who gets ahold of the code.
Being a contractor, I am faced with this problem a lot. Here is my 2 cents:
If it isn't broken, then the client is wasting their money having me change that. Unless I am rewriting the entire app, I usually keep with the old (bad) standards (at least that way, you don't have part of the app with one convention and other parts using something different - this keeps the code readable by other developers).
You have two options.
Change all the bad naming conventions to new ones.
Use the old conventions.
Someone will be looking at this code later and will need to deal with any differences you create. That means you need to be aware that other people are affected by this decision. Do the right thing if you have time, do the ugly thing if you don't have the time... but keep it consistant.
If it a constant style throughout the application I would follow the naming convention it will make it much easier on the next developer.
I tend to look at the scale involved. The consistency of a bad naming convention, to me, is preferable over a multitude of different ones in the same codebase or database.
If there are a handful of tables and you can safely change them, my feeling is to make the change. But anything of scale or an application that you're only doing a bugfix on is likely not worth the time and effort involved.
Go with which ever route costs less, in money and resources. If it's not going to save you money going through and re-tilling the ground, then don't. Just grit your teeth and move forward.
"If it ain't broke, don't fix it"
I think you should prefer consistency and follow the convention already being used.
Think of the poor developer(s) who come along behind you and have to deal with two different naming conventions (the original one and your new one), neither of which the new developers like.
Welcome to the world of maintenance. ;)
Who's to say that the next person who works on the site won't despise the way you did things?
Any naming convention is better than no/inconsistent naming convention.
I say change it iff there's a significant difference between the old code and the new code. For example, if the old way was a terribly dead-end and the new way is completely independent, then go ahead and start a new convention.
It's good to be visually consistent if the new material is structurally and semantically consistent, but if what you're doing is a clean break from what came before, then it's even more important that different things look different.
Like everyone said, stay with the bad convention since you are not writing it from scratch. However, use "good practice" if there is a compelling need for it (aka the end-user will be negatively affected otherwise). For example, if the "bad convention" makes the API users use boxing, change the value of strings and other performance-hit to a great degree; do not add to the problem! The end goal of software and API's is not to make the developers' life easier; but the end-user's. Developers that stay in the business long are highly aware of this and you want to be one of those developers.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
So I'm working on this class that's supposed to request help documentation from a vendor through a web service. I try to name it DocumentRetriever, VendorDocRequester, DocGetter, but they just don't sound right. I ended up browsing through dictionary.com for half an hour trying to come up with an adequate word.
Start programming with bad names is like having a very bad hair day in the morning, the rest of the day goes downhill from there. Feel me?
What you are doing now is fine, and I highly recommend you stick with your current syntax, being:
context + verb + how
I use this method to name functions/methods, SQL stored procs, etc. By keeping with this syntax, it will keep your Intellisense/Code Panes much more neat. So you want EmployeeGetByID() EmployeeAdd(), EmployeeDeleteByID(). When you use a more grammatically correct syntax such as GetEmployee(), AddEmployee() you'll see that this gets really messy if you have multiple Gets in the same class as unrelated things will be grouped together.
I akin this to naming files with dates, you want to say 2009-01-07.log not 1-7-2009.log because after you have a bunch of them, the order becomes totally useless.
One lesson I have learned, is that if you can't find a name for a class, there is almost always something wrong with that class:
you don't need it
it does too much
A good naming convention should minimize the number of possible names you can use for any given variable, class, method, or function. If there is only one possible name, you'll never have trouble remembering it.
For functions and for singleton classes, I scrutinize the function to see if its basic function is to transform one kind of thing into another kind of thing. I'm using that term very loosely, but you'll discover that a HUGE number of functions that you write essentially take something in one form and produce something in another form.
In your case it sounds like your class transforms a Url into a Document. It's a little bit weird to think of it that way, but perfectly correct, and when you start looking for this pattern, you'll see it everywhere.
When I find this pattern, I always name the function xFromy.
Since your function transforms a Url into a Document, I would name it
DocumentFromUrl
This pattern is remarkably common. For example:
atoi -> IntFromString
GetWindowWidth -> WidthInPixelsFromHwnd // or DxFromWnd if you like Hungarian
CreateProcess -> ProcessFromCommandLine
You could also use UrlToDocument if you're more comfortable with that order. Whether you say xFromy or yTox is probably a matter of taste, but I prefer the From order because that way the beginning of the function name already tells you what type it returns.
Pick one convention and stick to it. If you are careful to use the same names as your class names in your xFromy functions, it'll be a lot easier to remember what names you used. Of course, this pattern doesn't work for everything, but it does work where you're writing code that can be thought of as "functional."
Sometimes there isn't a good name for a class or method, it happens to us all. Often times, however, the inability to come up with a name may be a hint to something wrong with your design. Does your method have too many responsibilities? Does your class encapsulate a coherent idea?
Thread 1:
function programming_job(){
while (i make classes){
Give each class a name quickly; always fairly long and descriptive.
Implement and test each class to see what they really are.
while (not satisfied){
Re-visit each class and make small adjustments
}
}
}
Thread 2:
while(true){
if (any code smells bad){
rework, rename until at least somewhat better
}
}
There's no Thread.sleep(...) anywhere here.
I do spend a lot of time as well worrying about the names of anything that can be given a name when I am programming. I'd say it pays off very well though. Sometimes when I am stuck I leave it for a while and during a coffee break I ask around a bit if someone has a good suggestion.
For your class I'd suggest VendorHelpDocRequester.
The book Code Complete by Steve Mcconnell has a nice chapter on naming variables/classes/functions/...
I think this is a side effect.
It's not the actual naming that's hard. What's hard is that the process of naming makes you face the horrible fact that you have no idea what the hell you're doing.
I actually just heard this quote yesterday, through the Signal vs. Noise blog at 37Signals, and I certainly agree with it:
"There are only two hard things in Computer Science: cache invalidation and naming things."
— Phil Karlton
It's good that it's difficult. It's forcing you to think about the problem, and what the class is actually supposed to do. Good names can help lead to good design.
Agreed. I like to keep my type names and variables as descriptive as possible without being too horrendously long, but sometimes there's just a certain concept that you can't find a good word for.
In that case, it always helps me to ask a coworker for input - even if they don't ultimately help, it usually helps me to at least explain it out loud and get my wheels turning.
I was just writing on naming conventions last month: http://caseysoftware.com/blog/useful-naming-conventions
The gist of it:
verbAdjectiveNounStructure - with Structure and Adjective as optional parts
For verbs, I stick to action verbs: save, delete, notify, update, or generate. Once in a while, I use "process" but only to specifically refer to queues or work backlogs.
For nouns, I use the class or object being interacted with. In web2project, this is often Tasks or Projects. If it's Javascript interacting with the page, it might be body or table. The point is that the code clearly describes the object it's interacting with.
The structure is optional because it's unique to the situation. A listing screen might request a List or an Array. One of the core functions used in the Project List for web2project is simply getProjectList. It doesn't modify the underlying data, just the representation of the data.
The adjectives are something else entirely. They are used as modifiers to the noun. Something as simple as getOpenProjects might be easily implemented with a getProjects and a switch parameter, but this tends to generate methods which require quite a bit of understanding of the underlying data and/or structure of the object... not necessarily something you want to encourage. By having more explicit and specific functions, you can completely wrap and hide the implementation from the code using it. Isn't that one of the points of OO?
More so than just naming a class, creating an appropriate package structure can be a difficult but rewarding challenge. You need to consider separating the concerns of your modules and how they relate to the vision of the application.
Consider the layout of your app now:
App
VendorDocRequester (read from web service and provide data)
VendorDocViewer (use requester to provide vendor docs)
I would venture to guess that there's a lot going on inside a few classes. If you were to refactor this into a more MVC-ified approach, and allow small classes to handle individual duties, you might end up with something like:
App
VendorDocs
Model
Document (plain object that holds data)
WebServiceConsumer (deal with nitty gritty in web service)
Controller
DatabaseAdapter (handle persistance using ORM or other method)
WebServiceAdapter (utilize Consumer to grab a Document and stick it in database)
View
HelpViewer (use DBAdapter to spit out the documention)
Then your class names rely on the namespace to provide full context. The classes themselves can be inherently related to application without needing to explicitly say so. Class names are simpler and easier to define as a result!
One other very important suggestion: please do yourself a favor and pick up a copy of Head First Design Patterns. It's a fantastic, easy-reading book that will help you organize your application and write better code. Appreciating design patterns will help you to understanding that many of the problems you encounter have already been solved, and you'll be able to incorporate the solutions into your code.
Leo Brodie, in his book "Thinking Forth", wrote that the most difficult task for a programmer was naming things well, and he stated that the most important programming tool is a thesaurus.
Try using the thesaurus at http://thesaurus.reference.com/.
Beyond that, don't use Hungarian Notation EVER, avoid abbreviations, and be consistent.
Best wishes.
In short:
I agree that good names are important, but I don't think you have to find them before implementing at all costs.
Of course its better to have a good name right from the start. But if you can't come up with one in 2 minutes, renaming later will cost less time and is the right choice from a productivity point of view.
Long:
Generally it's often not worth to think too long about a name before implementing. If you implement your class, naming it "Foo" or "Dsnfdkgx", while implementing you see what you should have named it.
Especially with Java+Eclipse, renaming things is no pain at all, as it carefully handles all references in all classes, warns you of name collisions, etc. And as long as the class is not yet in the version control repository, I don't think there's anything wrong with renaming it 5 times.
Basically, it's a question of how you think about refactoring. Personally, I like it, though it annoys my team mates sometimes, as they believe in never touch a running system. And from everything you can refactor, changing names is one of the most harmless things you can do.
Why not HelpDocumentServiceClient kind of a mouthful, or HelpDocumentClient...it doesn't matter it's a vendor the point is it's a client to a webservice that deals with Help documents.
And yes naming is hard.
There is only one sensible name for that class:
HelpRequest
Don't let the implementation details distract you from the meaning.
Invest in a good refactoring tool!
I stick to basics: VerbNoun(arguments). Examples: GetDoc(docID).
There's no need to get fancy. It will be easy to understand a year from now, whether it's you or someone else.
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!
I have to agree that naming is an art. It gets a little easier if your class is following a certain "desigh pattern" (factory etc).
This is one of the reasons to have a coding standard. Having a standard tends to assist coming up with names when required. It helps free up your mind to use for other more interesting things! (-:
I'd recommend reading the relevant chapter of Steve McConnell's Code Complete (Amazon link) which goes into several rules to assist readability and even maintainability.
HTH
cheers,
Rob
Nope, debugging is the most difficult thing thing for me! :-)
DocumentFetcher? It's hard to say without context.
It can help to act like a mathematician and borrow/invent a lexicon for your domain as you go: settle on short plain words that suggest the concept without spelling it out every time. Too often I see long latinate phrases that get turned into acronyms, making you need a dictionary for the acronyms anyway.
The language you use to describe the problem, is the language you should use for the variables, methods, objects, classes, etc. Loosely, nouns match objects and verbs match methods. If you're missing words to describe the problem, you're also missing a full understanding (specification) of the problem.
If it's just choosing between a set of names, then it should be driven by the conventions you are using to build the system. If you've come to a new spot, uncovered by previous conventions, then it's always worth spending some effort on trying extend them (properly, consistently) to cover this new case.
If in doubt, sleep on it, and pick the first most obvious name, the next morning :-)
If you wake up one day and realize you were wrong, then change it right away.
Paul.
BTW: Document.fetch() is pretty obvious.
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.
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 ?
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.
I definitely feel you. And I feel your pain. Every name I think of just seems rubbish to me. It all seems so generic and I want to eventually learn how to inject a bit of flair and creativity into my names, making them really reflect what they describe.
One suggestion I have is to consult a Thesaurus. Word has a good one, as does Mac OS X. That can really help me get my head out of the clouds and gives me a good starting place as well as some inspiration.
If the name would explain itself to a lay programmer then there's probably no need to change it.
He is good programmer (won some competitions) but he absolutely ignores formatting.
He consider i, j, k beautiful... I hope he won't find out about existence of goto keyword.
Write some code in his "style" and then ask him to read it and explain to you what it is doing.
What's good for the goose and all...
I told my students (post-secondary) that they had the choice of writing code well or of me writing their assignments in the same sort of way that they wrote their code. I told them I would write the following program:
take the text of the assignment
lookup a number of the words in a thesaurus and replace them with obscure versions
remove all punctuation
remove all whitespace
convert everything to lower case
insert random whitespace
capitalize random letters
They could then have the assignment... hey its "right" (all of the words are there) good luck understanding what the assignment is though.
Oddly the complaints stopped at that point :-)
I also compared it to English. We use paragraph breaks, capitalizations, etc... as a convention. When someone chooses not to follow the conventions it makes reading much harder.
tell him about python :)
Make him maintain somebody else's code that's written the way he writes. Then make him maintain somebody else's code that was written with good style.
A combination of FORTRAN77 and Python should sort him out.
Code maintainability
Stuff I didn't care in high school neither :)
Write a bunch of "his" code and ask him to find a particular piece of code.
Give him some badly written code with a bug in it and ask him to find the bug.
Well, if he plans to do this for a living just explain that he will have a very rough life on a real team if he doesn't at least make some effort to follow the team standards. If he doesn't plan to do it for a living, don't worry about it.
You also might determine if there is anyone(s) that he admires. If there is then there is a pretty good chance that they follow standards.
I would point out that having clean code is a sign of a organized and intelligent mind. However, the real killer will be when he writes a large amount of code. I doubt you will be able to convince him because more than likely he is getting excited about the logic of the app and not the process. It will take experience to teach him a harsh lesson. So here are my suggestions.
Give him a project full of messy unformatted poorly named code and let him suffer.
Encourage him to work on a project with a large code base and let him see how well he remembers his own variable names after the 1,000th source file.
You probably can't.
Some people just don't get it.
I use self-describing variable names both at work and in private where noone tells me to. I also got some appreciation at work for using long and understandable names.
If a guy does not do it neither for himself or for your project then you've got that kind of guy. Show him some docs on the source code style policy. Explain why this is important.
You begin to use the right naming convention after you've got some experience and you see how and why this was useful. Without experience it's just an abstract talk.
P.S. Sometimes I get stuck with variable names because I'm not sure if this particular name does conform to the common linguistic style I use in the current project or how would the name scale on the high litterature language. The problem of using bool b1 vs. bool IsSomePropertyAvailable has never come up since the first university years.
I'm pretty sure you can misconfigure a code beautifier to present such horrible output. Obfuscaters are common, and do essentially the same thing (short useless variable names, no indenting, poor use of whitespace).
Give him the assignment of taking an existing program with his style and adding a trivial feature.
Also, take code he wrote 6 months or more ago and give the same assignment.
-Adam
Maybe he's not ignorant, maybe he's just inspired by Kernighan & Pike.
i,j,k is fine for loops.
I personally prefer using 1 letter vars in iterations...
foreach ($test as $t)
{
}
beautiful :D
When applying the Single Responsibility Principle and looking at a class's reason to change, how do you determine whether that reason too change is too granular, or not granular enough?
I don't know that there's a good answer to this one other than "apply your judgement, based on your experience." Failing that, get help, which I guess is what you're doing here ;)
Seriously, though, if you find that you're creating a gazillion classes to do what seems like a simple job, then you're probably being too granular. If your classes all seem collossal, then you're probably being too coarse. Please pardon me if that's a statement of the obvious.
I think this is one of those fuzzy, no-hard-and-fast-rules cases that show us why we need human programmers. Just try something, seeking balance, and refactor if you find you're going too far in one direction or the other. And remember: if it's worth doing, it's worth doing badly.
I wouldn't be too worried about granularity initially. I will just go with separation of concern at a broader level initially. Basic point is that we should avoid over-engineering here. But just enough. I agree with Lucas here, that this first step will improve with experience.
As the requirements change, as I am starting to get the 'smells', as my understanding of the problem improves I would refactor the design by factoring out the separate concerns as they become obvious. Basically separation of concern shall also be evolutionary as with overall design.