Some books said that we should avoid using names like 'XXInfo', 'XXManager' (I forgot the book name), so I try to find the good candidates for these names, but I can't find some good substitute for 'UserInfo', 'ProxyManager' or something like this.
Could anyone give some good advice about how to select the more expressive names? I'm not a English-speaking man
Instead of UserInfo, you could just call your class "User", especially if it is in a module called "Data" or "InfoStore" or something like that. The word "Info" conveys a meaning that can be taken for granted.
It's harder to get rid of the "manager" word - I have tried this myself. (Sometimes one ends up with so many "Managers" that one almost needs a "ManagerManager" to sort them all out.)
I think the important thing here, is to think "what does the class really do?"
Is it really a Wrapper, Helper, Retriever, Decider, Organiser, or Mapper?
If none of the above, then perhaps the "manager" class is simply too big, and should be split into separate functions that could be named accordingly.
In some cases, you might be able to replace the word "manager" with "boss", especially if it is a manager of other managers objects.
(Answer, because I couldn't fit this long post into the comments)
Related
I'm not a native English speaker and I'm wondering how's better to naming a variable with multiple words.
For example, I have two urls. One is for querying and the other is for submitting.
Should them be named as url_query, url_submit? Or querying_url, submitting_url? Or query_url, submit_url? Or things like submission_url?
I prefer url_query and url_submit. They are neat if I have a lot different urls for different purposes. But it sounds strange if I say it out.
This is a highly opinionated subject and it may be best to consult a specific coding style of your choice.
However, in general you want you variable names to be easily understood and readable.
For this reason items such as url_submit and url_query may be better option, as both are fairly understandable.
There are many different naming conventions, but the most important factor here is readability and implementation. Remember that comments will also help the readability as well.
You can name them however they feel right to you. Typically I camelCase them however instead of using underscores.
submitUrls/queryUrls
Try to think globally however as you may have these replicated in other pages and you may be able to build off your existing names like *action/*Thing(ie submit + what to submit "submitUrls")
Also, If something doesn't seem to make a good deal of sense to you when you're naming it. It is wise to add a line of comments in to identify what this function does later down the road if you have a bunch of functions named of actions and items.(Things)
When writing API methods that count something I always lose a tremendous amount of time thinking about how to write the thing that is being counted.
Singular or plural?
For instance, how would you name a function that counts results?
getResultsCount or getResultCount ?
This might sound silly, plural sounds more logical, but since both forms are found in the wild (google gives ~4800 results for "getResultCount" and ~4600 for "getResultsCount"), I'm hesitating and it bothers me.
Disclaimer: I'm not a native English speaker :)
Is there only one grammatically correct form or is it a matter of taste?
You should naming it basically for what it will do, if getResultsCount make mores sense than getResultCount, name it getResultsCount, else, name it getResultCount.
Its not that hard, Ill you have to do is give name that sweets better accordinling to the what it will do.
I suggest you read the book Clean Code written by Robert C. Martin, it really give good tips about naming.
Splitting a full name into first and last names is an unsolvable problem because names are really, really complicated. As a result, my model, which represents authors and other contributors to a book, includes both name and filingName fields, where filingName should usually be "Last, First" (for Western names).
However, as a convenience for my users, I'd like to have my app make a reasonable guess at the filing name when the user fills in the regular name. The user can edit the filing name if the guess is wrong, of course, but if I guess right, I'll have saved them some time. Currently I'm simply assuming the last space-separated "word" is the last name and moving it to the front with a comma:
NSMutableArray * parts = [self.name componentsSeparatedByCharactersInSet:NSCharacterSet.whitespaceCharacterSet].mutableCopy;
if(parts.count < 2) {
return self.name;
}
NSString * lastName = parts.lastObject;
[parts removeLastObject];
return [NSString stringWithFormat:#"%#, %#", lastName, [parts componentsJoinedByString:#" "]];
I can immediately think of one case where this will lead me astray: suffixes like "Jr". But I'm sure there are many others. Are there any good resources explaining common naming caveats, or good examples of code tackling this problem, that I can use to improve my heuristic? I'm using Objective-C on the Mac (in case there's some obscure corner of a framework that could help me), but I'm willing to learn from code written in any language.
This sort of question has been asked before, but most answers either focus on the mechanics of splitting apart a string, or devolve into "design your model differently". I am designing my model differently; I'm just looking to let the computer do most of my users' work for them.
As I said earlier, this code is mainly handling the names of authors and other contributors to books. Some of the specific ramifications of that include:
There should only be one name in name, because I support attaching multiple authors to a book.
Most names will not have titles, but professional titles like "Dr." could show up. Ideally these would be discarded, not treated as part of the first name.
The names will usually be of people, but could sometimes be of organizations. I'm perfectly willing to risk mangling organization names to get better person name handling.
I expect I will mostly be handling European names, although detecting the orthography of the name should not be difficult.
The code should not be particularly sensitive to the user's locale.
When you build a software system, there are always serious problems that consume a lot of time. I wouldn't get stucked with this because there is no worldwide naming conventions nor rules. I don't think asking the user to enter his/her filing name will be a bother, for they'll do it just once.
That seems to be the easier solution IMHO.
I need to define a class that represents a real-life event -- like a "movie premier", "party", etc. I will be creating a set of database objects to store the data for each event and define relationships with other data we have (e.g. venue, people, etc.).
The word "event" has a different meaning in the context of software, so I'd like to name the class something other than "event".
Any ideas on another name?
This related post asks a similar question, but I think all of the suggestions lack creativity -- basically #event, the case-sensitive name Event or use the old-school naming convention CEvent. Technically good solutions, but they don't help when discussing the data objects with peers (my speech and listening abilities are case-insensitive) and don't convey any information on how the class is not an event in the traditional use of the term.
One option would be CalendarEvent, to make it obvious that this is a real-world event tied to a given date.
Activity come to mind.
How about Happening or Occasion?
Normally I'd recommend function, but it too has specific meanings in the context of software. ;)
Occasion might be a good synonym.
The thesaurus lists the following as synonyms of the word event:
accident, act, action, advent,
adventure, affair, appearance,
business, calamity, case, catastrophe,
celebration, ceremony, chance,
circumstance, coincidence,
conjuncture, crisis, deed,
development, emergency, episode,
experience, exploit, fact, function,
holiday, incident, juncture, marvel,
matter, milestone, miracle,
misfortune, mishap, mistake, occasion,
occurrence, pass, phase, phenomenon,
predicament, proceeding, shift,
situation, story, thing*, tide,
transaction, triumph, turn, wonder
Surely one of them would suffice... if not, you can prepend or wrap the word event to make it a non-keyword. Something like #event or [event] although, I have to say that I don't personally like this practice even though it is syntactically permissable.
You could call it a 'Rendezvous'. You could also just make up a word. If this is a key concept in your domain you could abbreviate one of the other suggested names. Things like:
CalenderEvent becomes Calvent
SocialEvent becomes Socent
RealWorldEvent becomes Revent
HumanActivity becomes HAct
Those quick examples might be terrible examples but they are short, don't collide with language or library names, and will become real meaningful words for you and your coworkers very quickly if you work with them frequently.
Perhaps "Affair" or "Advent" -- you could also check the thesaurus:
http://thesaurus.reference.com/browse/event
Entry or EventEntry are probably what I would go with.
I can appreciate you want to avoid confusion with events in the programming sense, but my take on it is that maybe you should go with the most obvious name; program to your domain, and things stay readable and easier to design and maintain.
I'm sure this has already been asked and answered so I apologize in advance for that but I'm not figuring out the correct keywords to search for. Searching for "Pattern" hits way too many Q & A's to be useful.
I'm working on a regression testing app. I'm displaying a form on the screen and according to which user is logged in to the app some of the fields should be read-only. So I can abstract a field object and I can abstract a user object but what pattern should I be looking at to describe the intersection of these two concepts? In other words how should I describe that for Field 1 and User A, the field should be read-only? It seems like read-only (or not) should be a property of the Field class but as I said, it depends on which user is looking at the form. I've considered a simple two-dimensional array (e. g. ReadOnly[Field,User] = True) but I want to make sure I've picked the most effective structure to represent this.
Are there any software design patterns regarding this kind of data structure? Am I overcomplicating things--would a two-dimensional array be the best way to go here? As I said if this has been asked and answered, I do apologize. I did search here and didn't find anything and a Google search failed to turn up anything either.
Table driven designs can be effective.
Steve Maguire had few nice examples in Writing Solid Code .
They are also a great way to capture tests, see fit .
In your case something like:
Field1ReadonlyRules = {
'user class 1' : True,
'user class 2' : False
}
field1.readOnly = Field1ReadonlyRules[ someUser.userClass ]
As an aside you probably want to model both users and user classes/roles/groups instead of combining them.
A user typically captures who (authentication) while groups/roles capture what (permissions, capabilities)
At first blush it sounds more like you have two different types of users and they have different access levels. This could be solved by inheritance (PowerUser, User) or by containing a security object or token that sets the level for the user.
If you don't like inheritance as a rule, you could use a State pattern on the application, Decorate the user objects (Shudder) or possibly add strategy patterns for differing security levels. But I think it's a little early yet, I don't normally apply patterns until I have a firm idea of how the item will grown and be maintained.