Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've learned C/C++, Python, Matlab and many other language, but I was really surprised by the long method name in objective-c.
What's the advantage of using long name?
Why no other language use long name?
Thanks a lot.
It is something like code convention. Usually it is very useful.
But you can name your methods as you want. Also notice that it is not strongly required to name all parameters. For example you can create method
- (void)makeDateFromDay:(int)day month:(int)month year:(int)year
and call this way
[someObject makeDateFromDay:18 month:2 year:2014];
but you also can name it shorter
- (void)makeDateFrom:(int)day :(int)month :(int)year
and call like this
[someObject makeDateFrom:18:2:2014];
But it is not so readable, yes?
The plain answer is that the long method names are self-descriptive. (And since each argument is introduced through another method name part, the method name gets even longer.) The advantage is that the code reads really easily, and thanks to code completion there is no extra penalty for typing the whole thing by hand.
More methods are longer, more they speak themselves.
If you consider delegate method, in the method there is also the references
to class from the method being called because it can be very userfull to make some
kind of operation on class that conforms to protocol.
If you suppose to have an app where you have to do a lot of calc, like a shop application,
you can't declare all methods with the same name (for example sum) because when you have more than two methods with the same name you start to lose control on your code.
A lot of programmers using short syntax like name vars as:
a, b
But when you open code some months later you have to reconstruct the logic of program to know what a certain var does.
Give a long name to methods can be also usefull when you work in team to be more safe on method name replication.
Obj-C method names closely respect a convention with more rules than other languages. For example the last word of the method name is the name of the first argument.
- (id)valueForRow:(int)row Column:(int)column
In C++ this would probably be:
void getValue(int row, int column)
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Is there some authority recommendations what form of prefix should be used for UITableView (UICollectionView) - plural or singular? On example:
UserNamesTableView or UserNameTableView? (table that presents many users), or ObjectsTableView vs ObjectTableView (table presents many objects) etc.
Accordingly: UserNamesTableViewCell or UserNameTableViewCell?
The naming convention should be focused on the object that is defined with the class rather than the objects that can be hold by the class.
So if you name something User it should define an object that is definition of one user.Possibly kind of NSObject.
But if you name something Users you may have defined a Type/Class that can hold Users.Possibly kind of NSArray.
So a UserTableViewController is definition of one table that is meant to address User objects and not Users objects even if it can hold cells which are feed by Users and each shows content of one User.
So with UsersTableViewController i would expect a TableViewController that can mangle multiple users per cell and not one user per cell.
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/DefiningClasses/DefiningClasses.html#//apple_ref/doc/uid/TP40011210-CH3-SW1
So cause you asked for..
You can anser that allways when asking yourself what is the Object type that is defined and not what objects can be hold by the type.
What do would someone expect is UserTableView handling?
a TableView that handles objects of type User?
or a TableView that handles objects of type Users?
so the answer is quite simple. It would be most logic to use UserTableView.
In general the only rule is that you must not accidentally use a name that might be already in use by the built-in frameworks (because Objective-C has no namespaces). The way to avoid that is never to begin a type name with two prefix capital letters, such as ABThing, as that is what the built-in Cocoa frameworks do.
Starting with a word (so that the second character is a small letter) is generally fine, though in Swift you can never guarantee that you won't clash with an existing name (I see people make the mistake all the time in Swift of calling a type Data or Date, for instance).
Otherwise, no, there are no recommendations or rules; it would all just be a matter of convenience and convention. As a matter of best practices you should probably try to be clear as to what something is, but that's purely a matter of opinion right there.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Just a litle question about good practices in Object oriented programming.
Let's Image that I have a class like this (pseudo-code) :
class Activity{
construct(duration){
this.duration = duration
}
}
Now I want to define 2 types of Activities : "workTask" and "freeTime". I can imagine 3 possibilities :
Add a property to each instances of my class 'Activity'. Something like "Activity::type"
Inherite twice of the class "Activity" without changing anything exept the type of those classes. One would be "WorkTask" and the other "FreeTime"
Delegate the type assignement. The easier way might be by creating 2 arrays "workTasks" and "freeTimes" and store activities in those arrays.
I actually prefer the last choice but I don't know if it's the recommended way to do that stuff. Are those 3 patterns acceptable (even the second one that is in my opinion the weirder) ? Is there any other good ways to do it ?
Best practices calls for (1) "Add a property to each instances of my class 'Activity'. Something like 'Activity::type'"
This will allow you to:
Put all activities in the same array and still know which are which.
Change the activity type at runtime.
Separate an array of activities into two arrays.
Neither of the other two options is as flexible.
The answer to this kind of question is always "It depends". There are many factors to consider when choosing which approach to use.
If you need to check the type of activities a lot, then 3 is a bad idea, as you need to loop through arrays in order to find out whether a particular activity is a WorkTask or FreeTime.
If WorkTask and FreeTime differs in behaviour/data (e.g. WorkTime could have an extra taskName field or something), then you should use 2. Also note that even if they are the same now, it doesn't mean it will stay this way forever.
Both 1 and 3 will allow you to accidentally assign WorkTasks to variables that are supposed to store FreeTime. This might not be such a big problem in a dynamically-typed language, since you can do this with 2 anyway.
Don't forget that there are a fourth way: Composition
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Why did kotlin drop the new keyword ?
It makes it harder to see the difference between a function call and an object allocation.
The Kotlin Coding Conventions clearly state that:
use of camelCase for names (and avoid underscore in names)
types start with upper case
methods and properties start with lower case
If you follow the above and treat constructor as regular function that can be called i.e. val invoice = Invoice() the new keyword becomes redundant.
Once you accommodate yourself with the convention it's clear what a code is doing.
In fact even in Java code you'll have many implicit allocations that happen just beneath a method call like Collections.singleton(o) or Guava's Lists.newArrayList() so I don't think your argument about allocation visibility being better with the new keyword is fully valid.
(IMO) It was done because there is NO real difference between functions and object construction, i.e. nothing prevents a function to allocate an object (and they often do).
A good example is factory functions. These functions create new objects, but they are in no way class constructors.
AFAIK, the new keyword was created because of a negative experience with C\C++, where functions, returning new objects, have to be specially marked (by name conventions) in order not to forget to (manually) free the memory. In a auto-memory-managing language like Java\Kotlin it is not a concern.
Several other languages have no new keyword (Python, Scala, maybe Ceylon) and people who have switched to those languages never seem to miss it. I know I dont.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Simply put, is it a good idea to name collections and composite objects using plurality?
class PandaBears {
PandaBear[] bears;
class PandaBear {
}
}
My concern is that the class names are quite similar. On the other hand, PandaBearList reveals the implementation, but is more easily distinguishable.
I would prefer PandaBearCollection. A class name that is a countable noun just agrees better with the fundamental metaphor of OOP, an "object".
For example, try describing the signature of the following two functions:
void func(PandaBearCollection collection1, PandaBearCollection collection2);
void func(PandaBears pandaBears1, PandaBears pandaBears2);
The first one would naturally be: "A function that takes two collections of panda bears".
What would be the second one? "A function that takes two panda bears"? No, it just doesn't work.
I would avoid plurality.
If you don't want to include the suffix List, you could always use the suffix Collection which is a standard convention and does not reveal the implementation details. Of course this depends on the language you are using.
There is also a C#-specific work-around which I like to use if the structure is not very complex. You can avoid creating the Collection class at all, by declaring all the methods as extension methods of the related IEnumerable<T>. So, in this case, you could declare extension methods on IEnumerable<PandaBear>, provided that your collection does not have other private variables.
I prefer using plurality because as you mention it does not indicate the implementation, which could easily change in the future. Another consideration on the naming convention is if you are using an ORM and what type of convention will it use when translating your database schema, as discussed here. You will probably get a lot of advice both ways. I think what is more important is that you pick a convention that works for you and your team and you stick with it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm trying to figure out the best way to register my C++ Classes constructors with Lua (from a software design perspective, not a coding perspective)
How shall I do this ?
My Ideas:
1) Make some kind of "init Lua bindings" file which binds each of the C++ constructors that I want to have available in Lua ? (problem: this file would tend to get bigger and bigger and difficult to sync/debug)
2) Each class is responsable to register it's own constructor with my "LuaManager" Class
(problem: it would be stupid to bind the same constructor to Lua over and over again for the same Class of kind A, so ideally, each kind of scriptable Class should bind it's constructor with Lua only Once when using this approach.)
Ideas, or opinions are very welcome.
I understand what you mean by asking
from a software design perspective,
not a coding perspective
however I'm not sure there's clear distinction between the two. Or, more correctly, the coding approach you take will determine your design options. For example, if you use SWIG, the options in your question don't really make sense, since you write a separate "interface" file. If you are using luabind, the options do make sense, but I would definitely choose 1) in that case as luabind headers slow compilation dramatically and I'd like to have them included in as few compilation units as possible. If your "coding" approach doesn't have that luabind shortcoming then 2) seems like the more sensible thing to do.
Your second approach will work well. One way to avoid multiple registrations is to use a static initialization list approach. Each class would add a Lua registration function to a static std::set pre-main. Then you'd walk this std::set when your application starts and add each class constructor binding to your Lua runtime. This would ensure your class bindings are registered only once.