Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93720
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fleshgrinder.com from 77.244.243.84 cause and error)
Reply-To: internals@lists.php.net
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>
To: Ronald Chmara <ronabop@gmail.com>, internals <internals@lists.php.net>
Message-ID: <92b594e7-630e-d7ed-df67-04bdbb105762@fleshgrinder.com>
Date: Thu, 2 Jun 2016 18:59:47 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <CAFWS2+GKu04ULjm7m65B4U+YgE6KR-T4gJGrpi5wr7c8tr=0NA@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="2KhuoP7jimsoVa3ERPBK87pifaO576pO9"
Subject: Re: [PHP-DEV] [RFC] Libsodium - Discussion
From: php@fleshgrinder.com (Fleshgrinder)

--2KhuoP7jimsoVa3ERPBK87pifaO576pO9
Content-Type: multipart/mixed; boundary="rwKEvmJ3ER2Xe6omJ97LCat1rLTQweiEL"
From: Fleshgrinder <php@fleshgrinder.com>
Reply-To: internals@lists.php.net
To: Ronald Chmara <ronabop@gmail.com>, internals <internals@lists.php.net>
Message-ID: <92b594e7-630e-d7ed-df67-04bdbb105762@fleshgrinder.com>
Subject: Re: [PHP-DEV] [RFC] Libsodium - Discussion
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>
In-Reply-To: <CAFWS2+GKu04ULjm7m65B4U+YgE6KR-T4gJGrpi5wr7c8tr=0NA@mail.gmail.com>

--rwKEvmJ3ER2Xe6omJ97LCat1rLTQweiEL
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 6/1/2016 9:46 PM, Ronald Chmara wrote:
> Hi. https://github.com/php/php-src/commit/aa203477bc24b1fadc16d65533c17=
49162260592
> was my commit, put together as a result of discussions on this list
> (and sidebars). I can try to speak to it from memory.
>=20
>> Note that it also encourages this weird C style naming with
>> abbreviations, hence, I would be open for discussing it.
>=20
> It was 2000, 16 years ago.
>=20
> 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....
>=20
> ...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.
>=20
> 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.
>=20
> -Ronabop
>=20

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).

=46rom 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

--=20
Richard "Fleshgrinder" Fussenegger


--rwKEvmJ3ER2Xe6omJ97LCat1rLTQweiEL--

--2KhuoP7jimsoVa3ERPBK87pifaO576pO9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXUGYIAAoJEOKkKcqFPVVraqsQALaL7ucwBI7fsQwDZaChCpSh
4dKj5jAEskmepHUjHtcyxFJidKCqe0rglUTU25D45C+tid4tGDe+SMYmnwwMuXvi
MPn2wLyn/9ihDXT5Spu1QiQNAtWJ4JXTD+3z3bIK6iARNj7KjiZFNOlSaaN0fWFQ
ggMGlwFBAXpjd1BFeYROMDHzBKkVtg4Wzmxd5yLrCRpk8sVBb1jA+mawbIESxJhZ
PgZGaLo9CJaH6MbPIZD/jbMDuam/wB0Zag3hXpVC8Y8AKtBseT0MrEgD38bQWjUM
ifLV5mxXjJBrogIaDdmz+s8mK6mH0oh1/8BoTzWi2JaSovU0Mswhj4TvKRYqxt+Z
K48DsnxeSGXUWuSFJ5puk+KWTxTQDTC+m6cdYiNA/O7Bk9Z4DAqH/uS3Bw87gMaX
mB4q9jKDUR4GlrOJdIPIxJ5Ogt4LatZcpCjiX9p5XJ/2b+AP9tVe5X4rGiFWwZeM
33xWEeimcg+P7h1tnlKyPu6aS7XIxtbCWYUX+gX38ManCYfCkq3WL1a+sea26ZTE
JlbgFpMBd56LstxMSdwibwyG7Hjtbms2IceTBUiqe6Ytgr2FpBOF1iw/tRuITrTB
Q3myRnrCnUKLHCfppP5fcODbKR0eR3sMG7FgMkWqzSxlrFZQmnM/vbZsidihPveJ
gyj39oYh74m8sYwgybeX
=Trp5
-----END PGP SIGNATURE-----

--2KhuoP7jimsoVa3ERPBK87pifaO576pO9--