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.
Currently my best tool for this is a thesaurus, but I would like to expand my horizons on the matter.
Invest in a tool that makes refactoring easier. Like in NetBeans, you can easily rename classes and variables. If you use that, you can make a mistake without much problems.
But it is wise to think about the structure of names.
A class I think of as an entity, so its name is noun, like Customer is the name for a class respresenting a customer.
A function (and method too) is a verb. It describes what it does, like getName() returns the name. get and set are common prefixes for functions that return or set a property. That's why they're even called 'getters' and 'setters'. A function name could also be saveCustomer to save a customer, or just save, if it is a method of the customer class.
With some basic rules like that, it should be easy to come up with a reasonable name, which you can always change using the refactory tools found in many editors.
Sometimes it is hard to find a good name. I'm not a native english speaker myself, while the code I write (and the comments) is in english, because it conforms more to existing libraries. Sometimes I find it hard to find the right word. In that case I use a disctionary or just Google to find a translation. Usually googling for 'WordInYourLanguage translation' will give you a list of entries on dictionary sites, from which you probably will recognize the right term.
Sounds a bit OCD to me...
Most of my code does not face a 2nd pair of eyes, so I sometimes name my variables things such as "BigBoobs"... At the end of the day, the only people that need to know the variable are you and anyone else who may be looking at the code...
As for seriously addressing your question:
I don't think there would really be a variable name generator out there, because that would involve it knowing what your program is actually doing as you do it. If technology like that exists, I guess I will be out of a job.
Related
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 9 years ago.
Lately I have been struggling with method names in OOP and I decided to sort that out. For that purpose, I am trying to classify names of methods from natural language point of view. So far, I have figured out these categories:
1] Commands:
elem_list.append('x')
bank_account.deposit(50)
game.get_score()
append, deposit, get_score are commands here. You ask objects to do something (or ask interpreter to do something with them - depends on point of view). These methods contain a verb in various forms: just verb, verb + noun, verb + adjective + noun, sometimes noun + verb (to further clarify meaning of the verb). Commands are probably the most common names.
2] Queries:
connection.is_open()
snake.is_dead()
window.can_hide()
These are not so common. Their form is passive-verb + adjective (this form can be surely described better, I am not a native English guy). Basically, here you query about a state of an object.
The following are categories I am not sure about because I haven't really seen lots of method names like that (it can be my limited experience though):
3] Declarations:
button.widget_selected(event)
window.screen_changed(screen)
Here you notify an object that something has happened and expect it to do its job. The method is basically an event handler. The form is usually something like noun + passed-tense-verb. I am unsure about this category because you can transform it into a command just by prepending a verb e.g. handle: button.handle_widget_selected(event) which seems to be more natural when calling the method.
4] Noun-names
snake.crash_animation()
game.introduction()
I don't really like these because I think nouns should be reserved for data. And they can be transformed into the first category simply.
So my question is if you somehow agree with this classification and whether you consider names in the third and fourth category good or bad with respect to OOP paradigm.
I think you are looking for a style guide or coding standard.
e.g.
PEP-8 (common referred Python style guide)
Google JS styleguide
Having said that, imo it's better to be consistent throughout your coding than mixing in a style guide (stick to what you started with or refactor everything). Having your own scheme is fine, but you'd rather spend time on productivity.
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.
I have been researching and looking for answers here to a problem that I suspect might be solved by a better understanding of design patterns. I think the problem is that I am a self-taught coder and people seem to tend to assume familiarity with a lot of esoteric terminology; I have ended up in Wikipedia spirals trying to determine what some phrases mean.
That said - on to the coding/structural problem.
Actually, just before I start, I should point out that I may well be making unknown presumptions in the way the code is structured in my question. If this is the case, could folks suggest alternatives to what I'm suggesting? I'd really appreciate learning how to better code as opposed to simply being told I'm doing it wrong.
OK...
Let's say we have a Room class, which has 4 Walls, a Ceiling and a Floor. These are instantiated 'inside' the Room. The Room also has a Table which has 4 TableLegs, again instantiated inside the Table, inside the Room. (This, I believe, is Composition, but please correct me if I've got that wrong!).
Finally, the problem:
If someone, somehow, pushes the Table, the TableLeg(s) will need to check the type of Floor they're standing on to trigger the appropriate sound. This, currently would be my solution:
The Table dispatches an event. The Room listens for that 'table pushed' event, quizes the Floor to determine its type, then passes that type to a method on Table, which in turn passes it to the TableLegs.
This, to me, seems fairly inelegant; hence my suspicion that knowledge of design patterns might be useful.
Is there something fundamentally wrong about the structure I've described that I'm not appreciating? If so, what is the alternative?
Finally, I have heard of the Gang of Four book. If that's my first port of call, is it written in an accessible style or will I have to have studied computer science to grasp it?
Sorry for the long, design-pattern-beginner's question.
The Floor could listen for objects Events. The Event interface could expose information about object geometry, material, etc. Then the Floor could check for collisions and play a sound.
I recommend the book Head First Design Patterns
I don't know if I can answer your question, but I can tell you something about the "Design Patterns" book.
It was an instant classic when it was published in 1994/1995. With examples in C++ and Smalltalk (there was no Java or C# back then), it listed solutions to 26 common problems in object-oriented programming. It provided a format for documenting forces and resolutions that was eagerly snapped up by academic conferences for years after. Lots of programmers, including myself, were studying it like holy writ in the hope that a single book could make them superstars.
Then reality set in.
Functional programmers said the patterns were work-arounds for flaws in OOP. What's the fuss? They could do these things without resorting to patterns.
The usual response on first reading the book is to try and fit as many patterns as you can into whatever code you happen to be writing at that moment.
You'll find yourself using the pattern names in design sessions: "I think we need a Chain of Responsibility here!"
Eventually you calm down and realize that patterns aren't the answers to your problems. The best way to use them is to think hard about your problems and solutions and suddenly realize that your answer happens to fall into a pattern.
As for your problem, I don't think you need a pattern. Have the Table send a message to the Floor to ask about its type before you generate the sound. That'll do it. Simplicity is a virtue.
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 11 years ago.
I'd like to get some opinion of Naming Conventions for entity collections. In particular I'm designing a RESTful URI structure.
If I have an entity e.g. Account, I would call a collection of such entities Accounts. Similarly: Customer and Customers, Order and Orders. Generally adding an 's' to the end of the entity name. This is a consistent pattern good for a Naming Convention.
But what should I do when some plural words are not simply an 's' tagged on the end e.g. Mouse and Mice, Person and People or even Fish and Fish (plural and singular are the same)?
Should I stick with a simple pattern and just tag on a 's' irrelevant of English Language conventions, or go with the proper pluralised form of a word.
I've been tempted to name my collections e.g. PersonCollection or FishCollection but whilst consistent it is ugly and not the sort of thing I want to enter into URI which I want to be as succinct as possible.
Stick with the English language! It makes the code or the use of interfaces a lot more readable, maintainable and intuitive when somebody with a good understanding of the English language can sit down and work with it. It can be very frustrating to maintain code or interfaces that contain typos in class names, field names, URI parts, ... or other issues like using wrong plural forms as you mentioned. Therefore, I'd never use "Mouses" as the plural form for "Mouse".
Abbreviations might be of concern, too. If it's a known abbreviation, feel free to use it. However, try to keep one strict convention of naming them, like first letter is upper-case the rest lower-case, or all upper-case. Try to avoid mixing those.
Appending the type of the variable or field is like prefixing it. Depending on the programming language in question, I'd go with the general guidelines, e.g. in Java I'd remove the "Collection"-part. As far as URIs are concerned, I wouldn't use it. It doesn't improve readability.
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 12 years ago.
I don't think I am a total noob in OOP, but do you sometimes feel we go a little too far in privatizing the fields? Do you have a good rule of thumb as to when a field absolutely must be private, and when is it (maybe) okay to mark it protected, or public?
Sometimes it's the obvious thing that gets me.
Discuss
The simple rule:
Interface should be public. Implementation should be private.
When you make a field public (or even protected), you are effectively declaring it as part of the interface. Problem is, it's an implementation detail -- in almost every case, that field means something to your code. Anyone that wants to set it can, but you have to carefully explain how it needs to be set in order to keep the whole thing from crashing and burning. You can't even validate it as it's being set, so you need to validate it every...single...time before you use it, which can kill performance depending on how the validation needs to be done. (Even then, there's no guarantee that the field will stay valid, because you can't even enforce synchronized access to it.) And everyone using your class will have to do the same thing, cause $DEITY only knows what other code has been mucking around with that field and possibly corrupting it.
On top of all that, once it's a field, people are going to write code that expects to use that field. And in the cases where you find you need any of that validation later, you can't just convert a field to a getter/setter without breaking binary compatibility (meaning anyone who used your code will have to recompile everything that used that field in order for it to work again). Do that too many times, and people will be afraid to use your API -- read: you won't have any users.
Getters and setters separate the implementation from the interface. They allow callers to get back something that is definitely valid, and let you make sure that anything going in is definitely valid. This makes things more predictable, more stable. So if you write code that will ever be used after you write it, non-trivial getters and setters (that validate the value, maybe synchronize, etc -- ie: do more than just blindly get and set a variable) are a good idea.
It's for the case when others are going to be using your code or classes. You can expose and control exactly what is to be interfaced with, and what is 'internal.'
If you're the only one who will ever use your code, then yes it is often going 'too far.'
I will get attacked for even suggesting this, but whatever...
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.
What are some common practices you have seen used in the design by obfuscation crowd? I find it interesting to be on projects that are not allowed to be rewritten while, that would be the faster and most efficient solution to the problem.
My favorites always revolve around variables...leaving ones in the code that are no longer used, then giving them all meaningless names. Of course, you have to be careful to avoid nearly all convention if you really want to obfuscate. So, a perfect one would be to have two similarly used variables, one named myVar1, and another named myVarOne. Stuff like that...
Another one is to include un-used controls that are only visible within the code. I stared at one ASP.NET site for a good hour trying to figure out why a FormView was dropped into it..(there was no answer to that).
I once worked on perl code where the author decided to have most of the subs receive a single hash as a variable and returned that same hash with data added or removed. Basically one global hash used to pass data through the different code paths.
It looked something like this:
my $hash = ();
$hash->{'CUSTID'} = 1001;
$hash = GetAccounts($hash);
if ($hash->{'AccountTotal'} > 100) {
$hash = getTotals($hash);
$hash->{'Acct_Sbkt_Marker'} = 'R1';
$hash->{'Acct_Invr_Marker'} = 'BT';
$hash = removeInvalidAccount($hash);
}
To this day I can't figure out what design pattern he was trying to implement with this.
I remember the $hash would be lined up nicely.
We had one person we worked with store files in a folder call /kensington in order to "hide" them. It just contained some xml files that he didnt want seen and figured people wouldn't look in there.
No or useless comments in the code along with no useful documentation.
I worked with a programmer that used to write hugely complex conditions that when met would call a method that simply did a system out. He did this dozens of times throughout the entire app. Still not sure why....
And there I was thinking that well designed code should stand up on its own to be read, not deciphered.
I understand that people who care about obfuscation are encouraged to use tools like dotfuscator and its equivalents in other environments. Obfuscation in the sense of making the code harder to decompile though, not just making it a pain to work with.
Why anyone would deliberately design horrible code (except to demonstrate the gotchas) is beyond me.