Commenting code considered harmful

[Mr Flibble]

Verbose commenting of code (especially of implementation details) can be
dangerous as quite often the code evolves and old comments are not
updated in tandem with the code changes and become out of date no longer
reflecting what the code actually does. These erroneous comments can
have disastrous consequences if incorrect assumptions are made based on
them.

The best form of documentation is the code itself!

/Flibble

[Gareth Owen]

Mr Flibble <flibbleREM...@i42.co.uk> writes:

> Verbose commenting of code (especially of implementation details) can

> be dangerous ... The best form of documentation is the code itself!

Bravo! You have excelled yourself.

Expect a million bites, and not just on sausages.

[Christian Gollwitzer]

Am 03.02.16 um 18:44 schrieb Gareth Owen:

Where it hurts most :P

[Ian Collins]

Aren't you going to offer up your critique of Uncle Bob's TDD sausages?

--
Ian Collins

[Vir Campestris]

I'll bite. It can't make things wurst.

A good comment tells you what the code is supposed to do, and tells you
why it doesn't do something else that seems obvious.

The code tells you what it does. Nothing more.

Andy

[Paavo Helde]

On 3.02.2016 23:46, Vir Campestris wrote:
>
> A good comment tells you what the code is supposed to do, and tells you
> why it doesn't do something else that seems obvious.

I have written several comments for missing or deleted code, explaining
why something is not done or why some function is not called at this point.

[Mr Flibble]

Well written and designed code with sensible, descriptive variable,
function and class names is virtually self-documenting.

/Flibble

[Ian Collins]

Mr Flibble wrote:
>
> Well written and designed code with sensible, descriptive variable,
> function and class names is virtually self-documenting.

Especially if it was written with TDD where you have a lovely set of
tests that tell you exactly what the code does :)

[Mr Flibble]

Perhaps your problem is that you are confusing TDD with unit testing?
Unit tests are great, TDD isn't.

/Flibble

[Ian Collins]

Nope.

Aren't you going to offer up your critique of Uncle Bob's TDD sausages?

--
Ian Collins

[Öö Tiib]

Reading comprehension problem? Vir Campestris wrote above that code
can't answer without comments to question why it does what it does
and not something else that appears simpler. Can you demonstrate
that it can answer to that question? There are no point to write
those bald assertions.

If maintaining developer lacks that answer in code then she can
break some unit test naively and waste her time. If there are also no
unit tests that demonstrate the reason why then that typically results
with regression.

[Mr Flibble]

Nonsense. Why is not important, what is. If you were implementing
std::copy would you comment why? Of course not, the what is what is
important and the code itself tells you what.

/Flibble

[Öö Tiib]

Such comment is indeed needed when someone implements and uses
their own copy. Maintainer may otherwise look that it is pointless code
erase it and replace usages with 'std::copy'. However if there is comment
that
// because the destination remains intact on case of exception mid copy unlike with 'std::copy'
Then it is clear why it is used.

[Alf P. Steinbach]

I agree with all that.

Of course there are exceptions.

But in favor of your view, I once had to help a colleague with a little
Java class dealing with timestamps. I first sent her a simple
non-commented class she could use as starting point, and she was well
satisfied with that. However, our project coding guidelines required
comments on everything, to serve as automatically generated
documentation, and I had a little free time so I added what I thought
was reasonable commenting and sent that. This would be very helpful, I
thought, and the code was exactly the same. But now the clear
understanding evaporated, “I don't understand any of this!”.

I guess what happened was not that the comments misled intellectually,
but that with comments added the code LOOKED MORE COMPLICATED.

In a similar vein, my late father once thought he couldn't use my
calculator, because it looked so complex, lots of “math” keys. It didn't
matter that the keys he'd use were the same as on other calculators he'd
used. There was the uncertainty about the thing.

Francis Glassborow once remarked that the nice thing about the
introduction of syntax colouring was that one could now configure the
editor to show comments as white on white. ;-)

Which, I think, goes to show that your sentiment is not new, and is
shared by many who have suffered other's “well-commented” code.

Looks, not content.



Cheers,

- Alf

[David Brown]

Not long ago, I had the pleasure of bug-fixing code from a different
company that combined incompressible code, badly named variables and
functions, minimal commenting (some of which was other languages), and
no possibility of any sort of testing. However, the authors clearly
understood the importance of testing, since the one appropriate comment
was "// Test this shit!".

[JiiPee]

On 04/02/2016 11:17, Alf P. Steinbach wrote:
> On 2/3/2016 6:35 PM, Mr Flibble wrote:
>> Verbose commenting of code (especially of implementation details) can be
>> dangerous as quite often the code evolves and old comments are not
>> updated in tandem with the code changes and become out of date no longer
>> reflecting what the code actually does. These erroneous comments can
>> have disastrous consequences if incorrect assumptions are made based on
>> them.
>>
>> The best form of documentation is the code itself!
>
> I agree with all that.
>

Does this mean no comments at all, even not outside the code? Like I
make a code to handle 3 base numbers (as I need to have 3 values per
slot, not binary values like 101100, but could have 201200). Now
explaining the theory (and put couple of examples also) near that code
helps me when I come back year after. It speeds up things.
In a comment I tell what is the mathematical logic behind it and coupld
of short examples. Then its easy to understand the code after that.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Mr Flibble]

I guess we can summarize both those points as never document HOW you are
doing something as the code itself does that.

/Flibble

[JiiPee]

if I explain in the code also why I use that 3-base system, then it
helps to understand the code around it. The first question when seeing
3-base calculations there is: "why are we doing it like this? why use
3-base numbers here?". I did have that question when I came back to code
months after... and comments above it helped to undertand the motive
behind it.

The code does not answer questions like "why are we doing like this?
what is the motive doing this? why not doing another way? why is this
the best way to do this?"

[Alf P. Steinbach]

On 2/4/2016 1:32 PM, JiiPee wrote:
>
> if I explain in the code also why I use that 3-base system, then it
> helps to understand the code around it. The first question when seeing
> 3-base calculations there is: "why are we doing it like this? why use
> 3-base numbers here?".

That's because the NIM game with 3 heaps has a simple solution in base 3.

> I did have that question when I came back to code
> months after... and comments above it helped to undertand the motive
> behind it.
>
> The code does not answer questions like "why are we doing like this?
> what is the motive doing this? why not doing another way? why is this
> the best way to do this?"

Could be useful.

IMHO it all depends on whether the comments really add something that is
useful and can't be easily expressed in the code itself.


Cheers!,

- Alf

[Jerry Stuckle]

Well written code indicates WHAT it does.

Well written comments indicate WHY the code does what it does. It also
defines input and output conditions to a function, and other information
not part of the code.

Completely different things.


--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[JiiPee]

you mean not like this:

// here we are looping though all the humans in the vector and printing
their information!
for(const auto& a : humans)
a.print();


hehe

[Cholo Lennon]

On 02/04/2016 11:03 AM, Jerry Stuckle wrote:
> On 2/3/2016 6:19 PM, Mr Flibble wrote:
>> On 03/02/2016 23:09, Ian Collins wrote:
>>> Mr Flibble wrote:
>>>>
>>>> Well written and designed code with sensible, descriptive variable,
>>>> function and class names is virtually self-documenting.
>>>
>>> Especially if it was written with TDD where you have a lovely set of
>>> tests that tell you exactly what the code does :)
>>>
>>> Aren't you going to offer up your critique of Uncle Bob's TDD sausages?
>>
>> Perhaps your problem is that you are confusing TDD with unit testing?
>> Unit tests are great, TDD isn't.
>>
>> /Flibble
>>
>>
>
> Well written code indicates WHAT it does.
>
> Well written comments indicate WHY the code does what it does. It also
> defines input and output conditions to a function, and other information
> not part of the code.
>
> Completely different things.
>
>

+1 I fully agree


--
Cholo Lennon
Bs.As.
ARG

[Jorgen Grahn]

On Thu, 2016-02-04, Alf P. Steinbach wrote:
> On 2/3/2016 6:35 PM, Mr Flibble wrote:
>> Verbose commenting of code (especially of implementation details) can be
>> dangerous as quite often the code evolves and old comments are not
>> updated in tandem with the code changes and become out of date no longer
>> reflecting what the code actually does. These erroneous comments can
>> have disastrous consequences if incorrect assumptions are made based on
>> them.
>>
>> The best form of documentation is the code itself!
>
> I agree with all that.

Come to think of it, I do too. I disagree with the subject
"commenting code considered harmful", but the text you quote is fine
by me.

> Of course there are exceptions.
>
> But in favor of your view, I once had to help a colleague with a little
> Java class dealing with timestamps. I first sent her a simple
> non-commented class she could use as starting point, and she was well
> satisfied with that. However, our project coding guidelines required
> comments on everything

:-/ That's not documentation -- you weren't free to document things in
an optimal way. You were in effect being paid to make the
code worse and harder to maintain.

Part of the trick with good (or decent) documentation is to know what
to leave out, or let speak for itself. If that tool is not available,
the results will not be very good no matter how hard you try.

...
> Looks, not content.

Yes.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Andrea Venturoli]

On 02/04/16 15:03, Jerry Stuckle wrote:

> Well written code indicates WHAT it does.
>
> Well written comments indicate WHY the code does what it does. It also
> defines input and output conditions to a function, and other information
> not part of the code.
>
> Completely different things.

Thanks.
You spoke what I think, saying it far better than I could.




I've been struggling with collegues that write code like the following
(I simplified, obviously):

> /* Check that calling f with 4 as argument will fail;
> check that calling g(0) throws an exception;
> ....
> check that calling z(3,4) fails.*/
> BOOST_CHECK_THROW(f(4))
> BOOST_CHECK_THROW(g(0))
> ...
> BOOST_CHECK_THROW(z(3,4))

Think 20-40 lines of those comments, followed by the 20-40 lines of
code, which soon will get out of sync.



Of course, writing *why* something should fail would probably avoid
wading through hundred of pages of technical specs, but that would be
too good apparently.

[red floyd]

On 2/4/2016 10:38 AM, Andrea Venturoli wrote:

>
> I've been struggling with collegues that write code like the following
> (I simplified, obviously):
>
>> /* Check that calling f with 4 as argument will fail;
>> check that calling g(0) throws an exception;
>> ....
>> check that calling z(3,4) fails.*/
>> BOOST_CHECK_THROW(f(4))
>> BOOST_CHECK_THROW(g(0))
>> ...
>> BOOST_CHECK_THROW(z(3,4))
>
> Think 20-40 lines of those comments, followed by the 20-40 lines of
> code, which soon will get out of sync.
>

I once had the dubious "pleasure" of examining code where the standards
said that each function would have a block comment describing
functionality.

So far, so good.

However, this code was written in Ada by an idiot who figured that since
well written Ada code was "self-documenting", the block comment was
literally a commented out copy of the function.

Of course, the code was neither well written nor self documenting.

FWIW, my block comments look like this:

//
// func_name() -- one line description
//
// INPUTS: [input 1] -- description or NONE
// ...
//
// OUTPUTS: [output 1] -- description
// ...
//
// RETURNS: description, or NONE
//
// Short description of what function is intended to do and why
//

[red floyd]

On 2/4/2016 6:03 AM, Jerry Stuckle wrote:
> Well written code indicates WHAT it does.
>
> Well written comments indicate WHY the code does what it does. It also
> defines input and output conditions to a function, and other information
> not part of the code.

One time, I wrote a comment that was about five times the length of the
actual code. I was working on a Z80, and using 14-bit scaled fixed
point trig. To avoid losing precision when I multiplied the sines and
cosines, I had worked out a whole bunch of transformations that involved
adding angles instead of multiplying sin/cos.

The comment was the derivation of the transformations, since the code
was non-obvious. However, upon reading the comment, anyone familiar
with trig would understand what I had done, and why.

[Jerry Stuckle]

On 2/4/2016 1:38 PM, Andrea Venturoli wrote:
> On 02/04/16 15:03, Jerry Stuckle wrote:
>
>> Well written code indicates WHAT it does.
>>
>> Well written comments indicate WHY the code does what it does. It also
>> defines input and output conditions to a function, and other information
>> not part of the code.
>>
>> Completely different things.
>
> Thanks.
> You spoke what I think, saying it far better than I could.
>
>
>
>
> I've been struggling with collegues that write code like the following
> (I simplified, obviously):
>
>> /* Check that calling f with 4 as argument will fail;
>> check that calling g(0) throws an exception;
>> ....
>> check that calling z(3,4) fails.*/
>> BOOST_CHECK_THROW(f(4))
>> BOOST_CHECK_THROW(g(0))
>> ...
>> BOOST_CHECK_THROW(z(3,4))
>

That's even worse than the one I saw (from a "senior" programmer who
didn't like to write documentation and had to be forced to do so):

i++; /* increment i */

> Think 20-40 lines of those comments, followed by the 20-40 lines of
> code, which soon will get out of sync.
>
>
>
> Of course, writing *why* something should fail would probably avoid
> wading through hundred of pages of technical specs, but that would be
> too good apparently.

BTDTGTTS!

[Juha Nieminen]

Mr Flibble <flibbleREM...@i42.co.uk> wrote:
> Verbose commenting of code (especially of implementation details) can be
> dangerous as quite often the code evolves and old comments are not
> updated in tandem with the code changes and become out of date no longer
> reflecting what the code actually does. These erroneous comments can
> have disastrous consequences if incorrect assumptions are made based on
> them.
>
> The best form of documentation is the code itself!

You comment *what* the code does, not *how*.

Except in cases of very complex algorithms, where it just can't be
clear from the implementation itself how and why the algorithm works.
In that case it's good to explain the algorithm.

Without comments it's hard to remember months later what does what,
so they are really useful.

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Vir Campestris]

On 04/02/2016 19:16, red floyd wrote:
> One time, I wrote a comment that was about five times the length of the
> actual code.

The other day I put a comment against this:

char* workbuffer = malloc(strlen(input));

The code is correct. The first operation is guaranteed to remove at
least one char from the input, and put the rest in workbuffer. But it
looks wrong!

Andy
--
p.s. Didn't anyone like my German sausages?

[Paavo Helde]

On 4.02.2016 23:41, Vir Campestris wrote:
> On 04/02/2016 19:16, red floyd wrote:
>> One time, I wrote a comment that was about five times the length of the
>> actual code.
>
> The other day I put a comment against this:
>
> char* workbuffer = malloc(strlen(input));
>
> The code is correct. The first operation is guaranteed to remove at
> least one char from the input, and put the rest in workbuffer. But it
> looks wrong!

But you are missing a comment about using malloc()! This should be only
used in most low-level classes equivalent to std::vector, which should
not be aware any of such high-level business logic as "is guaranteed to
remove at least one char".

[Ian Collins]

Paavo Helde wrote:
> On 4.02.2016 23:41, Vir Campestris wrote:
>> On 04/02/2016 19:16, red floyd wrote:
>>> One time, I wrote a comment that was about five times the length of the
>>> actual code.
>>
>> The other day I put a comment against this:
>>
>> char* workbuffer = malloc(strlen(input));
>>
>> The code is correct. The first operation is guaranteed to remove at
>> least one char from the input, and put the rest in workbuffer. But it
>> looks wrong!
>
> But you are missing a comment about using malloc()!

Not to mention the missing cast...

--
Ian Collins

[Alf P. Steinbach]

On 2/5/2016 6:56 AM, Ian Collins wrote:

> Paavo Helde wrote:
>>
>> But you are missing a comment about using malloc()!
>
> Not to mention the missing cast...

Assuming it's C code there should be no cast, and of course malloc is OK
in C.

Cheers & hth.,

- Alf

[JiiPee]

yes, I have had this problem before.... its difficult to remember the
formulas and why they were there

[Scott Lurndal]

Vir Campestris <vir.cam...@invalid.invalid> writes:

>Andy
>--
>p.s. Didn't anyone like my German sausages?

One of the wurst jokes ever.

[Prroffessorr Fir Kenobi]

W dniu środa, 3 lutego 2016 22:47:08 UTC+1 użytkownik Vir Campestris napisał:

> On 03/02/2016 17:35, Mr Flibble wrote:
> > Verbose commenting of code (especially of implementation details) can be
> > dangerous as quite often the code evolves and old comments are not
> > updated in tandem with the code changes and become out of date no longer
> > reflecting what the code actually does. These erroneous comments can
> > have disastrous consequences if incorrect assumptions are made based on
> > them.
> >
> > The best form of documentation is the code itself!
> >

> > /Flibble
>
> I'll bite. It can't make things wurst.
>
> A good comment tells you what the code is supposed to do, and tells you
> why it doesn't do something else that seems obvious.
>
> The code tells you what it does. Nothing more.
>

> Andy

thats tru, code tells you what, comments could tell you why (which is probably a harder part of experience)

i am personally not writing this why comments though (i base on my memory,
it seems im mostly not forgeting why
i coded something given way even
15 years later)

[Prroffessorr Fir Kenobi]

eventually comments could describe a bit of what to - by describing the overview of architecture of some parts or of a whole
program - that could be helpfull even for the oryginal coder that this is probably some fault of language as c has probably no good way to express it locally (or at least probably clearly and fast) in the code

[Prroffessorr Fir Kenobi]

W dniu czwartek, 4 lutego 2016 22:40:34 UTC+1 użytkownik Juha Nieminen napisał:
> Mr Flibble <flibbleREM...@i42.co.uk> wrote:
> > Verbose commenting of code (especially of implementation details) can be
> > dangerous as quite often the code evolves and old comments are not
> > updated in tandem with the code changes and become out of date no longer
> > reflecting what the code actually does. These erroneous comments can
> > have disastrous consequences if incorrect assumptions are made based on
> > them.
> >
> > The best form of documentation is the code itself!
>
> You comment *what* the code does, not *how*.
>
> Except in cases of very complex algorithms, where it just can't be
> clear from the implementation itself how and why the algorithm works.
> In that case it's good to explain the algorithm.
>

when its algorithm you give its name

> Without comments it's hard to remember months later what does what,
> so they are really useful.
>

for me it is opposite when looking at my code much later i see clearer what i coded than in the moment i oryginally coded that
(recently i looked in my oldest codebase in c, and found that i had wrote bit dirty but very clear (this makes me a bit depressive
as today i know more (lost a very long time on that) but got not such clear material style

[Vir Campestris]

On 05/02/2016 07:21, Alf P. Steinbach wrote:
> Assuming it's C code there should be no cast, and of course malloc is OK
> in C.

As usual Alf gets it right ;)

It's in a Linux kernel driver.

Andy

[Juha Nieminen]

Prroffessorr Fir Kenobi <profes...@gmail.com> wrote:
>> Except in cases of very complex algorithms, where it just can't be
>> clear from the implementation itself how and why the algorithm works.
>> In that case it's good to explain the algorithm.
>>
> when its algorithm you give its name

Not all algoritms may have a unique name (as there is not necessarily one
unique way of implementing a certain algorithm). Also, you might not know
the name of an algorithms (or even if it has one.)

[Öö Tiib]

On Monday, 8 February 2016 11:18:32 UTC+2, Juha Nieminen wrote:
> Prroffessorr Fir Kenobi <profes...@gmail.com> wrote:
> >> Except in cases of very complex algorithms, where it just can't be
> >> clear from the implementation itself how and why the algorithm works.
> >> In that case it's good to explain the algorithm.
> >>
> > when its algorithm you give its name
>
> Not all algoritms may have a unique name (as there is not necessarily one
> unique way of implementing a certain algorithm). Also, you might not know
> the name of an algorithms (or even if it has one.)

+1
Also even if we know the name it might be unneeded clutter.

Compare "container.mostSignificantDigitRadixSortInPlace()" with "container.sort()".
The choice of algorithm is implementation detail of container, does not matter to
user and also may change. It is interesting only to developer who maintains the
sorting algorithm.

[Prroffessorr Fir Kenobi]

W dniu poniedziałek, 8 lutego 2016 11:23:27 UTC+1 użytkownik Öö Tiib napisał:
> On Monday, 8 February 2016 11:18:32 UTC+2, Juha Nieminen wrote:
> > Prroffessorr Fir Kenobi <profes...@gmail.com> wrote:
> > >> Except in cases of very complex algorithms, where it just can't be
> > >> clear from the implementation itself how and why the algorithm works.
> > >> In that case it's good to explain the algorithm.
> > >>
> > > when its algorithm you give its name
> >
> > Not all algoritms may have a unique name (as there is not necessarily one
> > unique way of implementing a certain algorithm). Also, you might not know
> > the name of an algorithms (or even if it has one.)
>

well i personally didnt met this case,
algorithms i used were always known one and
got names

> +1
> Also even if we know the name it might be unneeded clutter.
>
> Compare "container.mostSignificantDigitRadixSortInPlace()" with "container.sort()".
> The choice of algorithm is implementation detail of container, does not matter to
> user and also may change. It is interesting only to developer who maintains the
> sorting algorithm.

we are talking about comments (not function names)

it is better to said
//this is Cohen–Sutherland line clipping
than write whole description
where you can found it in hundreds of pages books etc

[Reinhardt Behm]

Prroffessorr Fir Kenobi wrote:

> W dniu poniedziałek, 8 lutego 2016 11:23:27 UTC+1 użytkownik Öö Tiib
> napisał:
>> On Monday, 8 February 2016 11:18:32 UTC+2, Juha Nieminen wrote:
>> > Prroffessorr Fir Kenobi <profes...@gmail.com> wrote:
>> > >> Except in cases of very complex algorithms, where it just can't be
>> > >> clear from the implementation itself how and why the algorithm
>> > >> works. In that case it's good to explain the algorithm.
>> > >>
>> > > when its algorithm you give its name
>> >
>> > Not all algoritms may have a unique name (as there is not necessarily
>> > one unique way of implementing a certain algorithm). Also, you might
>> > not know the name of an algorithms (or even if it has one.)
>>
>
> well i personally didnt met this case,
> algorithms i used were always known one and
> got names

So you never developed a new algorithm yourself which at that point in time
is nowhere else documented?

--
Reinhardt

[Öö Tiib]

I prefer just web link to some more stable site like
https://en.wikipedia.org/wiki/Cohen%E2%80%93Sutherland_algorithm

[Prroffessorr Fir Kenobi]

i dont think so,
Sometimes i had written more complex proceduress
take for example a code that reads rectangle part of texture and draws it on a screen with zoom and rotation (it is called 'rotozoomer' in demoscene, sometimes i expanded it to use a precomputed 2d-vector texture of distortion before drawing (that made nonlinear distortions
like various windowglass artifacts etc)
Maybe more such kind things but i wouldnt call it algorithms, it was not so much
hard to understand
(if some piece was harder it had a name)

Overall it is probably not much fortunate to learn some general techniques form source
you working on, where they got external world description - it is much more fortunate if a coder knows it from outside than come and see it here he understands it
Im not sure if a given code should act as a tutorial

[Prroffessorr Fir Kenobi]

name is better imo

[Paul N]

On Thursday, February 4, 2016 at 12:43:52 PM UTC, Alf P. Steinbach wrote:
> On 2/4/2016 1:32 PM, JiiPee wrote:
> >

> > if I explain in the code also why I use that 3-base system, then it
> > helps to understand the code around it. The first question when seeing
> > 3-base calculations there is: "why are we doing it like this? why use
> > 3-base numbers here?".
>
> That's because the NIM game with 3 heaps has a simple solution in base 3.

Drifting off-topic, but - are you sure about this? NIM (assuming you can only take from one pile at a time) has a simple solution in binary, regardless of the number of piles. It works best for the less-common "last man wins" version but can be easily tweaked for the more common "last-man-loses" version.

If you're allowed to take from up to two piles per turn, then base 3 does offer the solution (regardless of the number of piles). But this is much rarer - and it can't easily be tweaked for the "last-man-loses" version, as far as I know.

[Alf P. Steinbach]

On 2/8/2016 9:23 PM, Paul N wrote:
> On Thursday, February 4, 2016 at 12:43:52 PM UTC, Alf P. Steinbach
> wrote:
>> On 2/4/2016 1:32 PM, JiiPee wrote:
>>>
>>> if I explain in the code also why I use that 3-base system, then
>>> it helps to understand the code around it. The first question
>>> when seeing 3-base calculations there is: "why are we doing it
>>> like this? why use 3-base numbers here?".
>>
>> That's because the NIM game with 3 heaps has a simple solution in
>> base 3.
>
> Drifting off-topic, but - are you sure about this? NIM (assuming you
> can only take from one pile at a time) has a simple solution in
> binary, regardless of the number of piles. It works best for the
> less-common "last man wins" version but can be easily tweaked for the
> more common "last-man-loses" version.

You're right, I mis-remembered this.

Huh.

But then, I remember the two-heap game's solution as involving Fibonacci
numbers, which I calculated using the golden ratio (before knowing that
they were Fibonacci numbers), and there's nothing about that in the
Wikipedia article. Indeed the simple strategy of keeping the heaps equal
size, until the last move, suffices for 2 heaps. So I'm at a loss as to
what game or rules I remember strategies for...

> If you're allowed to take from up to two piles per turn, then base 3
> does offer the solution (regardless of the number of piles). But this
> is much rarer - and it can't easily be tweaked for the
> "last-man-loses" version, as far as I know.

Oh. Thanks!


Cheers,

- Alf