Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76235
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <71A78449-A62C-400D-A01F-5668930A7BED@ajf.me>
References: <CAMUwpuRJVmWwAMMdzAeoec=tvgkW1L++jxhDKjKbWvQNh5C7JQ@mail.gmail.com>
	<CAF+90c_HUkUQes2vt9x07+d7JMpt99DtEo9b9pRD_YQj6vF6TA@mail.gmail.com>
	<FCDF6A43-3935-4F1D-AC31-41BE47F4BAD2@ajf.me>
	<alpine.DEB.2.11.1407281459350.3793@whisky.home.derickrethans.nl>
	<71A78449-A62C-400D-A01F-5668930A7BED@ajf.me>
Date: Mon, 28 Jul 2014 23:14:13 +0400
Message-ID: <CA+9eiLvhPzb5OykP1HQAk-uWVZeKE4FYra_+AwdvM1FiEsJWvw@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Derick Rethans <derick@php.net>, Nikita Popov <nikita.ppv@gmail.com>, Julien Pauli <jpauli@php.net>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec52d57197c1fdd04ff45babc
Subject: Re: [PHP-DEV] Thoughts on C version supported for PHP-Next
From: dmitry@zend.com (Dmitry Stogov)

--bcaec52d57197c1fdd04ff45babc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think opinions about readability are subjective.

The real problem, that it'll break compatibility with old uncommon
compilers.
I'm not sure if new MSVC versions support it, but the one I use - does not.

Breaking something without a real reason is not a good move.

Thanks. Dmitry.




On Mon, Jul 28, 2014 at 6:19 PM, Andrea Faulds <ajf@ajf.me> wrote:

>
> On 28 Jul 2014, at 15:00, Derick Rethans <derick@php.net> wrote:
>
> >> Well, we don=E2=80=99t need to allow all of C99. We can simply allow u=
sing
> >> features that are widely supported and actually useful. For example,
> >> declarations between statements,
> >
> > I think that makes code a lot less readable, so I would not be in favou=
r
> > allowing this in our coding guidelines.
>
> Really? I=E2=80=99ve found that declaring everything in advance makes for
> hard-to-read code. To take an example from code I=E2=80=99ve written (adm=
ittedly
> not C code - GML if anyone=E2=80=99s curious - but it might as well be), =
the first
> line of a function looked like this:
>
>     var list, hashList, text, i, pluginname, pluginhash, realhash, url,
> handle, filesize, progress, tempfile, tempdir, failed, lastContact,
> isCached, env;
>
> Even broken onto multiple lines, declaring everything at once isn=E2=80=
=99t nice.
> For large functions (and some functions have to be large necessarily),
> declaring everything at the start just means a long list of variables and=
 I
> would argue impairs code readability.
>
> You should declare variables when and where you need them. If everything
> is done at the top, you have to scroll up to check the type of a variable=
.
> It also means that now-unused variables are less obvious as the
> declarations are far away from the usage, so you probably won=E2=80=99t s=
pot that
> it=E2=80=99s useless unless you look at your compiler warnings.
>
> Actually, a similar issue popped up in the code where that example was
> from. The language it was written in had some unfortunate properties, one
> of which was that variables not explicitly declared would instead be
> treated as properties of the current object. Because all the variables we=
re
> declared at the start of the function, it was easy to miss the fact that
> some variables being used had not actually been declared. Of course this
> specific issue doesn=E2=80=99t exist in C, but it is an example of why ha=
ving to
> declare all your variables at the start of a function isn=E2=80=99t reall=
y a good
> thing.
>
> If nothing else, I think we should use C99=E2=80=99s ability to declare v=
ariables
> between statements. It makes it more likely mistakes will be spotted, eas=
es
> reading code, and as far as I am aware, is widely supported.
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--bcaec52d57197c1fdd04ff45babc--