Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Donkey code

einarwh.wordpress.com

Post reply on HN
Print view View original

11–20 of 64 posts

Re: Donkey code

#11

Post by kbenson »

mcbishop wrote: post #9
gnulinux wrote: post #8

This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not…

Agreed. And might as well use one-syllable words that are pleasant to read / write (e.g. bob, tom, box, rack, sun).

The next thing you know your using joe[1] to write joe[2] in joe[3].

At work we have an app called "directly", and an app called "indirectly". Ask me if I ever have to clarify by asking "you mean in an indirect way, in the app indirectly or in the app directly?" (the answer is ALL THE TIME)

  1: the editor
  2: a service you created
  3: Joe-E the language

Re: Donkey code

#12

Post by gabrieledarrigo »

gnulinux wrote: post #8

This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not…

Nope! Things are never important... behaviour is!

And please, after 20+ years of DDD at least, give Evans some credit: name your things after your business domain...!

Re: Donkey code

#13

Post by gnulinux »

gabrieledarrigo wrote: post #12
gnulinux wrote: post #8

This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not…

Nope! Things are never important... behaviour is! And please, after 20+ years of DDD at least, give Evans some credit: name your things after your business domain...!

Well at the end of the day you will have to name your container, or instance, or server, or git repo, or db table etc... Conceptually I agree with you, behavior matters. But as the article details, when we communicate with humans, all we have is names, so we have to use names to communicate behavior.

> And please, after 20+ years of DDD at least, give Evans some credit: name your things after your business domain...!

This doesn't hold up in all companies. My company has more than 100 services (yeah yeah microservices suck yada yada, I don't make the decisions) you can't just name 150 things after your business domain, ultimately you're required to follow some kind of convention like "x {verb}er" etc.

Re: Donkey code

#14

Post by gnulinux »

kbenson wrote: post #11
mcbishop wrote: post #9

Earlier quoted context omitted.

Agreed. And might as well use one-syllable words that are pleasant to read / write (e.g. bob, tom, box, rack, sun).

The next thing you know your using joe[1] to write joe[2] in joe[3]. At work we have an app called "directly", and an app called "indirectly". Ask me if I ever have to clarify by asking "you mean in an indirect way, in the app indirectly or in the app directly?" (the answer is ALL THE TIME) 1: the editor 2: a service you created 3: Joe-E the language

Just use less common names like Brice or Werner or Rubin?

Re: Donkey code

#15

Post by DeathArrow »

gnulinux wrote: post #8

This is why I'm a big fan of "name it Steve" philosophy. When we create a new service many people are inclined to call it something like "rhombus keyboard fibriculator" or "octatonic runner". Usually it's of the form "{verb}er" or "{noun} {verb}er" or "{adj} {noun} {verb}er" or whatever. It's never accurate, and it's super confusing because chances are there is some other "{x} {y} {verb}er" with the same "verb". Not…

Kingdom of nouns?

Re: Donkey code

#17

Post by DeathArrow »

gnulinux wrote: post #13
gabrieledarrigo wrote: post #12

Earlier quoted context omitted.

Nope! Things are never important... behaviour is! And please, after 20+ years of DDD at least, give Evans some credit: name your things after your business domain...!

Well at the end of the day you will have to name your container, or instance, or server, or git repo, or db table etc... Conceptually I agree with you, behavior matters. But as the article details, when we communicate with humans, all we have is names, so we have to use names to communicate behavior. > And please, after 20+ years of DDD at least, give Evans some credit: name your things after your business domain...!…

>My company has more than 100 services (yeah yeah microservices suck yada yada, I don't make the decisions) you can't just name 150 things after your business domain

We did just that because each of our microservices does one thing. So we have Authorization, Notifications, Tenant, Workflow and so on.

Re: Donkey code

#18

Post by DeathArrow »

The problem is not with naming, the problem is with OOP, specifically inheritance and encapsulation.

You could have separate entities for horses, donkeys, mules, zebras and functions that work on them. Maybe less code reuse but state is kept separately, code is very easy to understand, modify and implement. And also is faster to implement.

If you have too many ifs in some functions you have to ask yourself if you architected the code well.

Re: Donkey code

#19

Post by knallfrosch »

karmakaze wrote: post #2

Besides the naming, the code examples because it uses an ask-then-do-different-things anti-pattern rather than Tell-Dont-Ask which implies defining distinct classes (or property values that define behaviors in the thing itself) rather than strewn across the codebase by interpretation, ie. there was no factoring only use-site decisions. The problem wasn't lack of naming , it was incomplete defining of the thing . If i…

> If it had a definition that everyone agreed upon

And there's your problem.

Post reply on HN