It could have been
interface
UnreceivedMasterOrdersInterfaceThatCanBeUsedToCallGetUnreceivedByProductsWarehouseAndCompany
Seriously, though, your example isn't even on the same planet as some
of the examples I've seen. (Neither is my parody.)
Sympathies.
-rob
On Tue, Mar 8, 2022 at 7:49 AM Ru
Latest interface my colleagues wrote (it's PHP)
---
interface UnreceivedMasterOrdersInterface
{
public function getUnreceivedByProductsWarehouseAndCompany(array
$productIds, int $warehouseId, int $companyId): array;
}
---
There is interest to switch to Go for some of the stuff we write, but I
Idiomatic naming in Go is one of the hardest things to communicate.
Everyone seems to bring the idioms from previous languages. Dave Cheney
writes about
"Lengthy bureaucratic names carry a low amount of signal compared to their
weight on the page".
Identifiers are not sentences or stand alone st
If I hired on to a company that enforced 3-4 line function calls I would be
looking for a job the next day.
> On Jan 31, 2022, at 6:44 PM, Rick wrote:
>
> Really? The idea that functions should never be longer than 2-3 lines is
> absurd. Functions should take an input, do one thing (without
Really? The idea that functions should *never* be longer than 2-3 lines is
absurd. Functions should take an input, do one thing (without side-effect)
and return a result. And their name should indicate what function they
compute. Whether that is 2-3 lines or 20-30 lines depends on the function.
> for _, otter := ListRiverOtters("europe")
> Calling this variable "otter" is great. Calling it "europeanRiverOtter"
is absurd - that's already there, obviously in the code.
Your "absurd" example is too charitable and naive. That's not even bad
compared to what I encounter day by day. Some wou
> Agree with Rudolf on point 2.
Then you completely misunderstood my point. Because I said exactly the
opposite. If your variable names are 10-15 words long (including
prepositions) then you should document what the function does.
On Saturday, January 29, 2022 at 1:21:19 PM UTC+2 timphar...@gmai
On Fri, Jan 28, 2022 at 1:12 PM Rudolf Martincsek wrote:
> > 2) Long variable names.
>
> Where I work (not in Go), writing comments is frowned upon. That includes
> "docblock" style comments. If a function needs to be documented, it means
> the implementation is too complex and must be broken apa
And there is that ... LOL. I normally ignore "goto", but yes it can be
turned into a looping construct. When refactoring code that uses "goto", I
would try to eliminate "goto" first. If it isn't possible, then the
execution flow must be so complex that it doesn't need to be broken down
further.
True, I don't say that meaningful names can entirely replace comments, just
that comments can't replace the sort of meaningful if verbose names that OP
objects to in point (1).
A lot must depend on the personal equation, how well one reads chunks of
camelCase, how well one reads abbreviations,
On Sunday, 30 January 2022 at 11:31:25 UTC Henry wrote:
> In Go, there is only one looping construct, which is the "for" keyword.
>
Don't forget "goto" :-)
<< ducks >>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this gr
Comments are useful to communicate what is not already apparent in your
code. Sometimes comments may help you find bugs in your algorithms. On the
other hand, keep your comments terse and not longer than what is necessary.
Respect other people's time.
Long names are not necessarily better. It
On Sat, Jan 29, 2022 at 6:21 AM Tim Hardcastle
wrote:
> Agree with Rudolf on point 2. Long meaningful variable/function names are
> good. Comments become obsolete, they become detached from their code,
> they're only used to explain the name of the variable once and then you're
> left with someth
Agree with Rudolf on point 2. Long meaningful variable/function names are
good. Comments become obsolete, they become detached from their code,
they're only used to explain the name of the variable once and then you're
left with something than reads
// urn contains the userlist
fxn := rx (frn)
> 2) Long variable names.
Where I work (not in Go), writing comments is frowned upon. That includes
"docblock" style comments. If a function needs to be documented, it means
the implementation is too complex and must be broken apart to reduce
cyclomatic or whatever perceived complexity. Also un
15 matches
Mail list logo
