[justasitsounds]

`is_foolike` is a bad name if you name your methods to only describe how they are implemented internally.

At a high-level, in your business domain, you generally write your code to hide the implementation details and to describe the intention of the method EG. `is_carbonated`

  if is_carbonated(beverage):
    beverage.jiggle(false)

vs

  if beverage.startswith("co2"):
    beverage.jiggle(false)

(edit) for formatting

[kerkeslager]

I'm sorry that this will come across as rude, but I feel like you're repeating something you've heard but didn't quite understand.

Yes, at pretty much ANY level, you should write your function names to hide the implementation details and to describe the intention of the function. In my previous post I hinted that the name of the function should "describe what the function does", which is the same as "describe the intention of the function", because if the function doesn't do what it's intended to do, that's a bug.

The reason I say I don't think you understand what you're saying is that none of what you're actually saying applies to the examples you're giving.

`is_foolike` doesn't describe the intention of the method. It gives an entirely vague and inaccurate view of what the method does. So even though we both agree that functions should describe the intention of the method, you're saying `is_foolike` is an okay name even though it doesn't do what you say it should?

`starts_with_foo` describes the intention of the method. It doesn't describe the implementation: `starts_with_foo(x)` might expand to `x.startswith('foo')` or `x[:3] == 'foo'`, but I don't care which, because the name accurately describes what it does either way.

Your example doesn't elucidate. If we're representing beverages as strings which are somehow guaranteed to begin with "co2" if the beverage is carbonated, and we've decided that the deserialization should be mixed into our "high-level, in your business domain", the program is so badly tangled that we're not going to get any truths about good programming from it.

[justasitsounds]

  I'm sorry that this will come across as rude, but I feel like you're repeating something you've heard but didn't quite understand.

You're right, it does come across as both rude and condescending, and you know it, so don't apologise.

  In my previous post I hinted that the name of the function should "describe what the function does", which is the same as "describe the intention of the function", because if the function doesn't do what it's intended to do, that's a bug.

`is_foolike` to me, implies `test_for_abstract_quality_foo`. `starts_with_foo` implies an assertion a string beginning with a particular prefix

  If we're representing beverages as strings which are somehow guaranteed to begin with "co2" if the beverage is carbonated, and we've decided that the deserialization should be mixed into your "high-level, in your business domain", the program is so badly written that we're not going to get any truths about good programming from it

I feel like you're intentionally misunderstanding my point. Please don't critique my entirely fictitious codebase as if it represents anything other than an abstract example. The point being that even though, in this (again) entirely fictitious example, the implementation is very simple, the intention of the method is different from it's implementation

[ju-st]

In your example `is_carbonated` is a private method. In an public interface you would want to hide the implementation details but surely not in a private method.