Am 03.02.2013 19:58, schrieb bearophile:
> Dejan Lekic:
>
>> In real projects people do the job as best as they
>> can at the moment,
>
> But often there's also some need for:
>
> http://en.wikipedia.org/wiki/Code_review
>
> Bye,
> bearophile


If only most companies I worked for cared about it, or for
that matter unit tests. :(

Am 03.02.2013 22:05, schrieb Peter Alexander:
> On Sunday, 3 February 2013 at 18:24:05 UTC, Dejan Lekic wrote:
>> Welcome to reality Bearophile!!!
>>
>> In real projects people do the job as best as they can at the moment,
>> and they probably, and with right, do not care what people who only
>> theorise, criticise, and philosophise think! You write perfect code?!
>> I doubt! And if you do, you will probably never finish any serious
>> project in time!
>
> That's besides the point. If people aren't using a feature of the
> language (e.g. contracts or const) then perhaps it is a sign of problems
> with those features, whether it be technical, or lack of tutorial, or
> poor documentation etc. I don't know if it is, but I find it interesting
> to observe how people use the language in real code.

Specially in offshore projects....

On Sunday, 3 February 2013 at 20:54:29 UTC, Nick Sabalausky wrote:
> Also, AIUI, "foreach(i; 0..10)" involves a range and function calls, so
> perhaps they want to be certain there isn't any overhead that
> accidentally fails to get optimized out?

There is no range or function calls! That syntax existed well before ranges were even conceived. It is nothing more than shorthand for the obvious for-loop alternative.

Best code, it's which works and the client is satisfied.

Nick Sabalausky:

> Why is it silly? (Genuine question)

"Silly" wasn't the right word, sorry.

But generally if a language offers you a clean feature (D contract programming is designed clean enough) it's better to use it, when you clearly need it.

In D you can live without D contract programming, but is useful, and it's better to know it.

(I'd also like Phobos to replace most of its usages of enforce() with asserts inside contracts.)

Bye,
bearophile

On Sun, 03 Feb 2013 22:15:09 +0100
"Michael" <pr@m1xa.com> wrote:

> Best code, it's which works and the client is satisfied.

And the end users are satisfied. AND doesn't cause problems when it inevitably needs maintenance. And isn't prone to crapping out or breaches of security.

On Sunday, 3 February 2013 at 22:00:05 UTC, bearophile wrote:
> Nick Sabalausky:
>
>> Why is it silly? (Genuine question)
>
> "Silly" wasn't the right word, sorry.
>
> But generally if a language offers you a clean feature (D contract programming is designed clean enough) it's better to use it, when you clearly need it.

I don't use D contracts, even though I use asserts.

I find that adding contracts bloats my code quite a lot, making it less readable.

real log(real x)
in
{
    assert(x > 0);
}
body
{
    return ...;
}

v.s.

real log(real x)
{
    assert(x > 0);
    return ...;
}

As far as I'm aware there is no difference except when inheritance is involved, so it's an easy choice for me.

Peter Alexander:

> I don't use D contracts, even though I use asserts.
>
> I find that adding contracts bloats my code quite a lot, making it less readable.
>
> real log(real x)
> in
> {
>     assert(x > 0);
> }
> body
> {
>     return ...;
> }
>
> v.s.
>
> real log(real x)
> {
>     assert(x > 0);
>     return ...;
> }
>
> As far as I'm aware there is no difference except when inheritance is involved, so it's an easy choice for me.

If you have to create some temporary values (or to perform some computation) for your asserts you probably want to put this code inside a {} to avoid such names to spill inside the body of the function.

There are also post-conditions, that catch all the returns you have in your function, unlike free asserts.

There are also loop invariants, missing in D contract programming:
http://d.puremagic.com/issues/show_bug.cgi?id=9300

Also, a well designed language enforces pre and post conditions to not mutate values (this is an ongoing discussion in D: http://d.puremagic.com/issues/show_bug.cgi?id=9408 ), and offers you the "old" (prestate) feature only inside contracts (missing still in D contract programming). Contracts also make life a little simpler for static analysis tools (that aren't yet available in D).

So the better contract programming is implemented in a language (and its tools), the more useful it is compared to using free asserts.

Bye,
bearophile

On 02/03/2013 11:14 PM, Peter Alexander wrote:
> On Sunday, 3 February 2013 at 22:00:05 UTC, bearophile wrote:
>> Nick Sabalausky:
>>
>>> Why is it silly? (Genuine question)
>>
>> "Silly" wasn't the right word, sorry.
>>
>> But generally if a language offers you a clean feature (D contract
>> programming is designed clean enough) it's better to use it, when you
>> clearly need it.
>
> I don't use D contracts, even though I use asserts.
>
> I find that adding contracts bloats my code quite a lot, making it less
> readable.
>
> real log(real x)
> in
> {
>      assert(x > 0);
> }
> body
> {
>      return ...;
> }
>

If the code is written consistently in this vertically-bloated style, it is 'less readable' anyway. Contracts will not make a huge difference. :o)


> v.s.
>
> real log(real x)
> {
>      assert(x > 0);
>      return ...;
> }
>

real log(real x) in{ assert(x > 0); }body{
    return ...;
}

real log(real x) in{
    assert(x > 0);
}body{
    return ...;
}

> As far as I'm aware there is no difference except when inheritance is
> involved, so it's an easy choice for me.

The difference is that the first version of log given above may be correct whereas the second is certainly buggy (pass in 0 and it fails). As correctness is not necessarily modular, the entire code base as a unit may still work correctly if it contains either version. That's why your approach is practicable in the absence of a tool/review process that checks assertions in a modular way.

Yes, you are right. But it's all is just nuances )))