/coding-like-shakespeare-practical-function-naming-conventions/

[panzerdp]

Written on 10/10/2016 12:14:32

URL: https://dmitripavlutin.com/coding-like-shakespeare-practical-function-naming-conventions/

[panzerdp]

Comment written by Emilio Fernández on 10/23/2016 22:21:47

Using "get-" to prefix getters is just more noisy and kind of inherited from other programming languages IMO. absoluteDifference or calculateAbsoluteDifference are better names that getAbsolute...
Moreover, in Cocoa the word get is reserved to funcions that receive an argument by reference and return its value through it (C structs normally).

[panzerdp]

Comment written by WoanVersace on 10/24/2016 10:27:46

`Coding like Shakespeare`. But he also created a lot of new vocabularies and then explanted them, or no one can understand.
Normal naming, don't Shakespeare. And write documents/comment to explant code.
anw, this is good article.

[panzerdp]

Comment written by Dmitri Pavlutin on 10/24/2016 13:13:14

Interesting opinion @disqus_qQIbJamRYP:disqus!
Not sure if `get` word has to do with a specific language. It just indicates to get a value.
The simple `absoluteDifference` is not the best solution for a method name, since it doesn't have a verb that indicates action. `absoluteDifference` fits much better for a computed property (and this solution is probably more swifty!).
`calculateAbsoluteDifference` seems like an alternative, but in my opinion is too verbose.

[panzerdp]

Comment written by Dmitri Pavlutin on 10/24/2016 13:13:59

`Coding like Shakespeare` is a metaphor :). It means that you can review many times a function name and refactor it until you find a meaningful name. (The way writers change the script many times until reaching a nice version).
So yes, do Shakespeare.

Not sure about "normal" naming. The name should be concise and meaningful. It should explain clearly the intent of the function.

The code should be self-explanatory and self-documented. Writing comments in most of the cases is a bad practice, because you try to "explain" with comments the code that is badly written. Let the code explain by itself - and this is the primary goal of correct naming.

The best use case for documentation is designing a public API. In other cases (with a very few exceptions) comments are code smell.

[panzerdp]

Comment written by Gaston Sanchez on 11/01/2016 01:09:16

It definitively is an interesting opinion. The first I time heard such idea was from Uncle Bob on its amazing book clean code.

Google for "clean code getters" for some good reads.

I was trying to explain why calculateAbsoluteDifference might be a better name for the function than getAbsoluteDifference but I think that Marcus Biel explains it better

http://www.marcus-biel.com/...

> As a final note, I’d like to highlight that we didn’t add the “get” prefix to our identifier as it decreases the readability of our code and shifts the code from an Object Oriented Design to a more procedural machine-like model.

[panzerdp]

Comment written by Christian Tietze on 11/13/2016 15:30:16

+1 that: Array.first is even easier to grasp than a verbose getFirstElement, for example.

For consistency, the get prefix rule of thumb would eliminate property accessors – no matter if they’re computed or stored. Resolving the conflict in favor of getters “just because” is just opinion. People argue that computed properties expose data you can bind to other components, so there’s an upside to exposing things instead of actions in some cases. Your rule of thumb rules out the former completely.

[panzerdp]

Comment written by Frederik Krautwald on 10/05/2018 07:55:37

> Variables are nouns and functions are verbs.

How about boolean variables? It has been advocated in Code Complete to prefix them with `is`, `has` or `should`, etc. E.g., `isUserAuthenticated`.

[panzerdp]

Comment written by KaPweT on 04/18/2019 14:03:12

if you need to comment your code thats because your are a monkey coder

[panzerdp]

Comment written by KaPweT on 04/18/2019 14:13:36

ban setter and getter is obliviously as nonsense as using them all time, the key is balance indeed.

[panzerdp]

Comment written by Hank Thetank on 05/27/2019 08:43:48

I arrived at a point where I believe one should avoid boolean.
Use enums instead. I know this is controversial, but boolean is horribly non-self-explanatory.
I started by not using boolean for function parameters if possible...

anyways - is, has and should makes sense to me too, if I use bool.

[panzerdp]

Comment written by Michal Miky Jankovský on 05/27/2019 20:50:04

can you be more concrete?
`one should avoid boolean` `is horribly non-self-explanatory`
it `is self-explanatory` in number of options... in case of enum I have to check definition (and hope the list is complete)

I hate thinks like makeIt('john', false, false, true)
modern IDEs solves it by default with writing parameter names... ;)

[panzerdp]

Comment written by Hank Thetank on 05/28/2019 13:10:51

Exactly the example you showed.

The IDE is only helping if you are inside th IDE. Also - true is a not very fluent to read for typical flags:

PerformOperation(someparam, true);
with the IDE showing:
PerformOperation(someparam, isUserAuthenticated: true);
especially with
PerformOperation(someparam, isUserAuthenticated: true);
I would prefer
PerformOperation(someparam, UserIsAuthenticated)
with:
enum authenticationStatus
{
UserisAuthenticated,
UserNotAuthenticated
}

I have to admit - the example could be better

[panzerdp]

Comment written by Ognian Baruh on 07/12/2019 11:49:34

If a programmer writes 20 functions and another programmer needs one, a comment before every function about what it does would save a lot of time to the second programmer.

[panzerdp]

Comment written by Dmitri Pavlutin on 07/12/2019 12:13:03

The name of the function and the name of the parameters chosen correctly are enough to understand "how to use" the function.

But if you have chosen bad naming, and compensate bad naming with comments, you're actually wasting the time of the second programmer forcing him to read comments.

My advice is to choose function names that don't need comments (maybe with the exception of public APIs).

[Chris-Chuba]

I love the content. Any chance you could produce a bullet list at the end of the article. This would be for people who want to use this as a reference and do not need to be converted. :-)

Unreasonable? Just asking you to make a list based on your naming conventions. To only use enough text to make the meaning descriptive and unambiguous.