On Friday, 7 June 2013 at 07:42:15 UTC, Peter Alexander wrote:
> On Thursday, 6 June 2013 at 20:50:08 UTC, David Nadlinger wrote:
>> On Wednesday, 5 June 2013 at 20:49:19 UTC, Walter Bright wrote:
>>>> uses C printf (!) in the examples,
>>>
>>> Again, trying to make it lightweight.
>>
>> … and wrong, in more than one way.
>>
>> David
>>
>>
>> (What happens if the input is larger than 'uint.max / 2 + 1'? Than 'uint.max' on a 'size_t.sizeof == 8' target?)
>
> Not sure what you're getting at. I can only see 2 uncommented calls to printf, and neither do any formatting, so I'm not sure how they'd be wrong?

'%d' isn't the correct format specifier for size_t. The code will still run on 64 bit systems (at least with the common ABIs out there), but print wrong values for long inputs.

Using an API that is known to be error-prone even in the C world simply has no place in the Phobos documentation.

David

On Friday, 7 June 2013 at 13:47:59 UTC, David Nadlinger wrote:
> On Friday, 7 June 2013 at 07:42:15 UTC, Peter Alexander wrote:
>> On Thursday, 6 June 2013 at 20:50:08 UTC, David Nadlinger wrote:
>>> On Wednesday, 5 June 2013 at 20:49:19 UTC, Walter Bright wrote:
>>>>> uses C printf (!) in the examples,
>>>>
>>>> Again, trying to make it lightweight.
>>>
>>> … and wrong, in more than one way.
>>>
>>> David
>>>
>>>
>>> (What happens if the input is larger than 'uint.max / 2 + 1'? Than 'uint.max' on a 'size_t.sizeof == 8' target?)
>>
>> Not sure what you're getting at. I can only see 2 uncommented calls to printf, and neither do any formatting, so I'm not sure how they'd be wrong?
>
> '%d' isn't the correct format specifier for size_t. The code will still run on 64 bit systems (at least with the common ABIs out there), but print wrong values for long inputs.
>
> Using an API that is known to be error-prone even in the C world simply has no place in the Phobos documentation.

Ah right, sorry. Didn't notice you were talking about the documentation. My bad!

On 2013-06-05 23:14, Jonathan M Davis wrote:

> Given that pretty much every program is going to use std.stdio in one form or
> another, I see little point in avoiding using it. And since it's an example,
> it makes even less sense. I would even argue that using printf is bad
> practice. writeln and writefln are properly typesafe, whereas printf is not. If
> you really actually _need_ to restrict how much you're importing, then using
> printf makes sense, but in general, it really doesn't.

printf is even worse in D than in C. That's because most modern C compilers will give warnings if you use printf incorrectly.

-- 
/Jacob Carlborg

On 2013-06-05 22:48, Walter Bright wrote:

> si - source index
> di - destination index
>
> Not random. Would you prefer i and j? :-)

It might not be obvious what they mean. I would prefer sourceIndex and destinationIndex.

-- 
/Jacob Carlborg

On Sunday, June 09, 2013 21:25:55 Jacob Carlborg wrote:
> On 2013-06-05 22:48, Walter Bright wrote:
> > si - source index
> > di - destination index
> > 
> > Not random. Would you prefer i and j? :-)
> 
> It might not be obvious what they mean. I would prefer sourceIndex and destinationIndex.

Well, we could go somewhere in between those and do something like srcIdx and dstIdx. Short doesn't necessarily mean hard to understand or non-obvious. The trick is to pick abbrevations which are clear. But if you can't, then I tend to think that longer, more descriptive names are better than short ones, especially when you consider that more people than just you may have to maintain the code later.

- Jonathan M Davis

On 6/9/13 6:59 PM, Jonathan M Davis wrote:
> On Sunday, June 09, 2013 21:25:55 Jacob Carlborg wrote:
>> On 2013-06-05 22:48, Walter Bright wrote:
>>> si - source index
>>> di - destination index
>>>
>>> Not random. Would you prefer i and j? :-)
>>
>> It might not be obvious what they mean. I would prefer sourceIndex and
>> destinationIndex.
>
> Well, we could go somewhere in between those and do something like srcIdx and
> dstIdx.

Guys, they're function local vars. A comment would suffice.

Andrei

Jacob Carlborg:

> printf is even worse in D than in C. That's because most modern C compilers will give warnings if you use printf incorrectly.

The ldc2 compiler has this switch:

  -check-printf-calls                          - Validate printf call format strings against arguments

Bye,
bearophile

On 2013-06-10 05:40, bearophile wrote:

> The ldc2 compiler has this switch:
>
>    -check-printf-calls                          - Validate printf call
> format strings against arguments

Cool, I didn't know that.

-- 
/Jacob Carlborg

On 2013-06-10 04:33, Andrei Alexandrescu wrote:

> Guys, they're function local vars. A comment would suffice.

That doesn't mean the names should be less understandable. We're writing open source here. I think most names should be named as if they were part of the public API.

It also depends on in what context they are used. Example, in DMD there are a lot of functions containing probably more the 500 lines of code with variable names with only one letter, declared at the top of the function. If you instead have a function with only five or ten lines of code it could be ok:

private void foo (ProductInformation pi) { // five lines of code }

I would think the above would be ok. But it should definitely not be used in documentation/examples as I see it is now.

BTW, I hate using comments for that. Comments should basically only be used for writing API documentation. Most times, if you want to add a comment your code is probably not clear enough.

-- 
/Jacob Carlborg

On 6/10/2013 12:13 AM, Jacob Carlborg wrote:
> Most times, if you want to add a comment your code is
> probably not clear enough.

There's no way to put the "why" in code.