Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93738
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain telia.com from 81.236.60.154 cause and error)
To: Fleshgrinder <php@fleshgrinder.com>, Ronald Chmara <ronabop@gmail.com>
References: <CAKws9z114YcHkDaXO3o-E0JuHR10WsPzyedeF_8Q=shHDziwug@mail.gmail.com>
 <CADyq6sKr_6qi4Fnk9+yxgCA5j_xF7B7vxq7HH5_nneax5bLf5A@mail.gmail.com>
 <295c09d5-01af-1528-8e61-00dc6ee6c69e@fleshgrinder.com>
 <CAFWS2+GKu04ULjm7m65B4U+YgE6KR-T4gJGrpi5wr7c8tr=0NA@mail.gmail.com>
 <92b594e7-630e-d7ed-df67-04bdbb105762@fleshgrinder.com>
Cc: PHP internals <internals@lists.php.net>
Message-ID: <07264e27-2120-3e80-79d0-1a1115bb391b@telia.com>
Date: Fri, 3 Jun 2016 11:19:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <92b594e7-630e-d7ed-df67-04bdbb105762@fleshgrinder.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Libsodium - Discussion
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)

Den 2016-06-02 kl. 18:59, skrev Fleshgrinder:
> On 6/1/2016 9:46 PM, Ronald Chmara wrote:
>> Hi. https://github.com/php/php-src/commit/aa203477bc24b1fadc16d65533c1749162260592
>> was my commit, put together as a result of discussions on this list
>> (and sidebars). I can try to speak to it from memory.
>>
>>> Note that it also encourages this weird C style naming with
>>> abbreviations, hence, I would be open for discussing it.
>> It was 2000, 16 years ago.
>>
>> WRT: "C style naming": C style PHP, *was* a big part of the PHP
>> adoption base in 2000. No objects. No inheritance. No classes. No
>> namespaces. Folks were also coming to PHP from ColdFusion, from Perl,
>> from JavaScript, and bringing their language conventions with them.
>> Without many guide rails, there was a weird mix of CreaTive_nameing
>> (and spelling). Conventions like verbnoun, Noun_Verb,
>> parent_Verb_noun, Parent(Noun())....(and most imaginiable
>> permutations) were sprinkled throughout the code, throughout
>> documentation, throughout the community... and one of the earliest
>> public complaints about PHP was about about inconsitent function
>> naming. The goal was to bend the curve, over the years, to bring some
>> order and consistency, not just to internal function naming (as in
>> this case), but to the entire PHP ecosystem. Thus, the standards about
>> parent naming, about underscores and....
>>
>> ...Abbreviation: In 2000, most PHP code was typed, manually, No IDE
>> completion, no built-in syntax checking, no code generators, every
>> single keystoke was a human hammering away in emacs/vi, BBedit,
>> Notepad (etc.), and longer function names tended to decrease code
>> quality (due to increased human error potential), and take up valuable
>> screen space (800x600 pixels on emergency terminals, though a nice
>> developer setup could have had 1024x768 pixels on a screen, all *at
>> the same time*.)  Coding houses still had rules like "maximum of 80
>> characters per line", to encourage brevity. Abbreviation in this
>> environment made for more compact code, with less typing errors, but
>> came with the costs of inconsistent abbreviations, and decreased
>> readability.
>>
>> In 2016, using an editor with built in syntax highlighting,
>> auto-completion, while at coding desks measuring in thousands of
>> pixels across multiple screens, it seems a bit dated, but when
>> debugging text files with vi on a spare monochrome terminal session,
>> late night over a modem at 3,600 Kbps, those things mattered a great
>> deal. For folks who are still using modems, terminals, and updating
>> their PHP on 800 pixel screens, I imagine they might still matter.
>>
>> -Ronabop
>>
> This is a nice story but it simply is not true at all. You refer to the
> beginnings of the 21st century as if it was the 1970/80s.
>
> Steve McConnell: Code Complete, Second Edition
>
>> Make names of routines as long as necessary
>>
>> Research shows that the optimum average length for a variable name is
>> 9 to 15 characters. Routines tend to be more complicated than
>> variables, and good names for them tend to be longer. Michael Rees of
>> the University of Southampton thinks that an average of 20 to 35
>> characters is a good nominal length (Rees 1982). An average length of
>> 15 to 20 characters is probably more realistic, but clear names that
>> happened to be longer would be fine.
>>
>> A study by W. J. Hansen found that longer names are better for rarely
>> used variables or global variables and shorter names are better for
>> local variables or loop variables (Shneiderman 1980). Short names are
>> subject to many problems, however, and some careful programmers avoid
>> them altogether as a matter of defensive-programming policy.
>>
> The first edition of the book contains these passages as well, it was
> released in 1993 and the years of the studies are already in the quotes.
>
> I know that there are many valid reasons for short names as well as
> appropriate and I know that there are certain domains where long names
> are not even possible or make no sense in the first place.[1] However,
> PHP is a high level programming language that does not suffer from such
> limitations. The only relation to C is the fact that PHP's underlying
> engine is in C. Users of PHP are not familiar with C and very often not
> familiar with any programming language other than the ones for the web
> (e.g. JavaScript).
>
>  From our own source:
>
>    zend_rsrc_list_get_rsrc_type()
>
> How is that more readable or faster to type than any of the following
> who are human readable and much clearer?
>
>    zend_typeof_resource()
>    zend_resource_type()
>    zend_get_resource_type()
>
> [1] http://programmers.stackexchange.com/questions/162698
>
One could add that not all development / debugging is done through
an advanced IDE. Logging in to production server with SSH ending up
with a terminal window, only having Emacs or Vi at your disposal is
still valid today.

Regards //Björn Larsson