Re: [RFC] Libsodium - Discussion

From: Date: Fri, 03 Jun 2016 09:19:41 +0000
Subject: Re: [RFC] Libsodium - Discussion
References: 1 2 3 4 5  Groups: php.internals 
Request: Send a blank email to internals+get-93738@lists.php.net to get a copy of this message
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

« previous php.internals (#93738) next »