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 8 years ago.
Improve this question
Method naming is done seeing objects as some data on which we operate, thus getValue means I'm getting the value. Though, in the method's description, we always read about the object doing something, and not us.
When it's about object's own data, shouldn't we choose method names from the object's point of view?
Thus, since the object gives its value, then method's name would be giveValue.
While the "setter" would be named getValue, since the object is getting the value.
My (annoying) question is mainly because of the get term, used for both retrieving data from the object or asking the object retrieve data from somewhere.
getValue → "return the value"
getData → "call another object and get some data"
By your own logic, I would say it is called Get because the object gets a value from its internal data, and returns it to the caller. The meaningful action here is getting the data, which varies depending on the property, and not returning it to the user, which is constant.
Other than that, the point of naming methods is to give them names that would make it very clear what they do. Naming your setter GetValue would be nothing short of sadistic to your user.
When it's about object's own data, shouldn't we choose method names from the object's point of view?
No because in essence the object is simply a container which we use to store/carry information. Programming is about writing code which is easy to use & understand from the developers point of view, not an objects.
Think of it as a conversation with the object:
Object please get me your value; object please set your value.
Only less polite because this is programming not etiquette school.
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 needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have read why to use classes, but I don't understand how it makes my program better?
My example: I made a class called "PanelList" and within it are several subs and a few functions that all use related information that will Arrange panels, resizes panels, and Save/Load information from a database. I access it from my main form using:
dim myObj as new PanelList()
myObj.Gap = 20
myObj.ArrangePanels(Panel1, Panel2)
Why is that better than if I would just do something like this from a module which seems much more condensed and I don't have to create a new instance:
ArrangePanels(Panel1, Panel2, 20)
I would think creating a new instance of an object would take more resources, and if I need to create several objects it starts to make my code look unorganized in my view?
So why would I use my own Objects??
The function you describe in your question isn't really object-oriented, so indeed it doesn't sound like it would make much sense to create an object for it. It's just a helper function that you want to put somewhere.
Objects are exactly that... objects. They are "things" which are described semantically by attributes and operations. For example, you might have a Person object. It's not just a dumping ground for random functions, but rather a discrete instance representing a "person". It has data describing that instance of a person, it has operations that can be performed on or by a person, etc.
If you're not doing any object-oriented programming then, no, you don't really need objects. But if your domain space has discrete semantic concepts of "things" which can be packaged into objects, then it would make sense to do so.
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 4 years ago.
Improve this question
In his book "Clean Code", Robert Martin states that the ideal number of function arguments is zero. Most people will agree that too many function arguments cause lots of issues. But as far as I can see, a function with zero arguments belongs to at least one of these categories:
The function is trivial and always returns the same value.
The function lacks referential transparency, its return value depends on external mutable state.
The purpose of the function are its side effects.
Now functions of type (1) are not really useful while (2) and (3) should be avoided for well-known reasons.
I am aware that the book I mentioned is about OOP, so functions typically belong to an object and get an object reference passed as an implicit argument. But still, accessing object attributes either means (2) or (3).
So what am I missing?
If you answer this question, please don't just communicate your opinion but provide reasonable arguments or specific examples. Otherwise it will probably get closed.
So what am I missing?
The key word in Martin's statement is "ideal". If you continue reading, he writes in depth about functions with one, two, and three arguments, but only mentions niladic functions in one context - testing. He claims that they are trivial to test, presumably because there is only one possible outcome, and it's either right or wrong.
So this is an ideal, and the principle to take from it is the fewer arguments, the better. In reality, obviously, this ideal is rarely achieved. The purpose of a function is usually to take input, whether directly, or indirectly through the object or system state (note that I would call those "arguments" as well to be consistent with Martin's analysis), and provide an output. When you have multiple arguments, the number of test cases increase exponentially, the maintenance is more difficult, etc.
So you are not "missing" anything, so long as you recognize that this is an ideal goal and not something that you should take as an absolute.
Some examples of "pure" niladic functions in C#:
DateTime.MinValue
String.Empty
Niladic functions in C# that return object or system state:
DateTime.Now()
object.GetHashCode()
String.Length
The object's attributes will essentially serve as the arguments to the function. In this way, you can directly manipulate the object you are working with, rather than passing and returning values which you then attribute to the object after performing some behaviour contained in the function.
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 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)