Starting the 3.0 branch

classic Classic list List threaded Threaded
93 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

localheinz

> What do you think ?

Can't tell what it's called, but since we are telling a story, order of appearance makes a lot of sense.

Obviously you will start with a constructor, add a method, add another, extract a method, etc. the order is more or less natural, I believe. Extracted method goes right underneath the method from which it was extracted, etc.

Ordering stuff alphabetically is a pain, especially when someone adds a method and starts reordering everything alphabetically. You don't want to diff that, eh?

Best regards,

Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

localheinz
In reply to this post by Corentin Larose - QAPA

> What do you think ?

Newspaper metaphor, it is.

http://wiki.eclipse.org/Recommenders/CleanCodeMethodSorter


Best regards,

Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Frank Brückner
In reply to this post by Corentin Larose - QAPA
Hi Corentin,
my opinion:

1. This is a job for your IDE.
2. There are more important tasks than this. (e.g. bugs, missing  
documentation, …)


Kind regards,
Frank


Am 27.07.2013, 09:34 Uhr, schrieb Corentin Larose  
<[hidden email]>:

> Hello eveyone,
>
> I would like to propose a Coding Standard (or convention) for the
> methods order in a class.
>
> - Since there is no real trivial order to respect, you can often observe
> two adapters having the same methods in a different order.
>
> - Since we most often use IDEs, we have a methods list somewhere which
> we are able to class more or less the way we want.
>
> It seems that ordering methods in a class by alpha order is the only
> trivial/consensual possibility (often used also in css).
>
> Some special pre order could happen for
> static/private/protected/public/magic methods, even if I'm not sure if
> it would be very interesting.
>
> Intended goal would be to be able to put a new method in a class without
> wondering each time where.
>
> What do you think ?
>
> Regards,
>
> Corentin Larose - Paris
>
> CTO & Co-founder @ QAPA
Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Matus Zeman
I use combination of method grouping and ordering (of groups).
First goes PHP "__" methods like: __construct, __toString, ...
Second methods forced by interfaces.
Then other methods where I try to keep related methods together.
Last are getters/setters.

I don't think ordering of methods should be forced into coding standard but it might be considered as a recommendation - but please nothing like alpha ordering where you'll spend more time keeping the order right than coding useful stuff.

Regards,
Matus


On 27 July 2013 15:09, Frank Brückner <[hidden email]> wrote:
Hi Corentin,
my opinion:

1. This is a job for your IDE.
2. There are more important tasks than this. (e.g. bugs, missing documentation, …)


Kind regards,
Frank


Am 27.07.2013, 09:34 Uhr, schrieb Corentin Larose <[hidden email]>:


Hello eveyone,

I would like to propose a Coding Standard (or convention) for the
methods order in a class.

- Since there is no real trivial order to respect, you can often observe
two adapters having the same methods in a different order.

- Since we most often use IDEs, we have a methods list somewhere which
we are able to class more or less the way we want.

It seems that ordering methods in a class by alpha order is the only
trivial/consensual possibility (often used also in css).

Some special pre order could happen for
static/private/protected/public/magic methods, even if I'm not sure if
it would be very interesting.

Intended goal would be to be able to put a new method in a class without
wondering each time where.

What do you think ?

Regards,

Corentin Larose - Paris

CTO & Co-founder @ QAPA

Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Luis "Kindaian"
Method reorder adds noise to the source control, by marking changes where no change occurred (similar to white space changes from tab / spaces and elimination of end of line spaces).

Noise is bad.
LF


On 2013/07/27 09:23, Matus Zeman wrote:
I use combination of method grouping and ordering (of groups).
First goes PHP "__" methods like: __construct, __toString, ...
Second methods forced by interfaces.
Then other methods where I try to keep related methods together.
Last are getters/setters.

I don't think ordering of methods should be forced into coding standard but it might be considered as a recommendation - but please nothing like alpha ordering where you'll spend more time keeping the order right than coding useful stuff.

Regards,
Matus


On 27 July 2013 15:09, Frank Brückner <[hidden email]> wrote:
Hi Corentin,
my opinion:

1. This is a job for your IDE.
2. There are more important tasks than this. (e.g. bugs, missing documentation, …)


Kind regards,
Frank


Am 27.07.2013, 09:34 Uhr, schrieb Corentin Larose <[hidden email]>:


Hello eveyone,

I would like to propose a Coding Standard (or convention) for the
methods order in a class.

- Since there is no real trivial order to respect, you can often observe
two adapters having the same methods in a different order.

- Since we most often use IDEs, we have a methods list somewhere which
we are able to class more or less the way we want.

It seems that ordering methods in a class by alpha order is the only
trivial/consensual possibility (often used also in css).

Some special pre order could happen for
static/private/protected/public/magic methods, even if I'm not sure if
it would be very interesting.

Intended goal would be to be able to put a new method in a class without
wondering each time where.

What do you think ?

Regards,

Corentin Larose - Paris

CTO & Co-founder @ QAPA


Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Bas Kamer
But surely correct formatting is a good thing. When is a good time to add those kind of 'non' changes?

When code is change anyway. Or in a separate commit/pr? Or not at all? I tend to mix them into code changes when I see a discrepancy or in separate commits, usually after the CI failed due to the pho-cs-fixer check.


On 27 jul. 2013, at 12:26, Luis Ferro <[hidden email]> wrote:

Method reorder adds noise to the source control, by marking changes where no change occurred (similar to white space changes from tab / spaces and elimination of end of line spaces).

Noise is bad.
LF


On 2013/07/27 09:23, Matus Zeman wrote:
I use combination of method grouping and ordering (of groups).
First goes PHP "__" methods like: __construct, __toString, ...
Second methods forced by interfaces.
Then other methods where I try to keep related methods together.
Last are getters/setters.

I don't think ordering of methods should be forced into coding standard but it might be considered as a recommendation - but please nothing like alpha ordering where you'll spend more time keeping the order right than coding useful stuff.

Regards,
Matus


On 27 July 2013 15:09, Frank Brückner <[hidden email]> wrote:
Hi Corentin,
my opinion:

1. This is a job for your IDE.
2. There are more important tasks than this. (e.g. bugs, missing documentation, …)


Kind regards,
Frank


Am 27.07.2013, 09:34 Uhr, schrieb Corentin Larose <[hidden email]>:


Hello eveyone,

I would like to propose a Coding Standard (or convention) for the
methods order in a class.

- Since there is no real trivial order to respect, you can often observe
two adapters having the same methods in a different order.

- Since we most often use IDEs, we have a methods list somewhere which
we are able to class more or less the way we want.

It seems that ordering methods in a class by alpha order is the only
trivial/consensual possibility (often used also in css).

Some special pre order could happen for
static/private/protected/public/magic methods, even if I'm not sure if
it would be very interesting.

Intended goal would be to be able to put a new method in a class without
wondering each time where.

What do you think ?

Regards,

Corentin Larose - Paris

CTO & Co-founder @ QAPA


Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Marco Pivetta

@bas those changes are ok only when the PR queue is empty and a complete rewrite happens. As luis said, they just introduce problems.

On 27 Jul 2013 12:43, "Bas Kamer" <[hidden email]> wrote:
But surely correct formatting is a good thing. When is a good time to add those kind of 'non' changes?

When code is change anyway. Or in a separate commit/pr? Or not at all? I tend to mix them into code changes when I see a discrepancy or in separate commits, usually after the CI failed due to the pho-cs-fixer check.


On 27 jul. 2013, at 12:26, Luis Ferro <[hidden email]> wrote:

Method reorder adds noise to the source control, by marking changes where no change occurred (similar to white space changes from tab / spaces and elimination of end of line spaces).

Noise is bad.
LF


On 2013/07/27 09:23, Matus Zeman wrote:
I use combination of method grouping and ordering (of groups).
First goes PHP "__" methods like: __construct, __toString, ...
Second methods forced by interfaces.
Then other methods where I try to keep related methods together.
Last are getters/setters.

I don't think ordering of methods should be forced into coding standard but it might be considered as a recommendation - but please nothing like alpha ordering where you'll spend more time keeping the order right than coding useful stuff.

Regards,
Matus


On 27 July 2013 15:09, Frank Brückner <[hidden email]> wrote:
Hi Corentin,
my opinion:

1. This is a job for your IDE.
2. There are more important tasks than this. (e.g. bugs, missing documentation, …)


Kind regards,
Frank


Am 27.07.2013, 09:34 Uhr, schrieb Corentin Larose <[hidden email]>:


Hello eveyone,

I would like to propose a Coding Standard (or convention) for the
methods order in a class.

- Since there is no real trivial order to respect, you can often observe
two adapters having the same methods in a different order.

- Since we most often use IDEs, we have a methods list somewhere which
we are able to class more or less the way we want.

It seems that ordering methods in a class by alpha order is the only
trivial/consensual possibility (often used also in css).

Some special pre order could happen for
static/private/protected/public/magic methods, even if I'm not sure if
it would be very interesting.

Intended goal would be to be able to put a new method in a class without
wondering each time where.

What do you think ?

Regards,

Corentin Larose - Paris

CTO & Co-founder @ QAPA


Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

ThaDafinser
Hello together,

as the ZF2 components can now be installed independently, wouldn't it make sense that also the unitTests get seperated? So when only e.g. Zend\Filter is installed, testing is also possible.

(maybe this was already suggested, but i couldn't find)


2013/7/27 Marco Pivetta <[hidden email]>

@bas those changes are ok only when the PR queue is empty and a complete rewrite happens. As luis said, they just introduce problems.

On 27 Jul 2013 12:43, "Bas Kamer" <[hidden email]> wrote:
But surely correct formatting is a good thing. When is a good time to add those kind of 'non' changes?

When code is change anyway. Or in a separate commit/pr? Or not at all? I tend to mix them into code changes when I see a discrepancy or in separate commits, usually after the CI failed due to the pho-cs-fixer check.


On 27 jul. 2013, at 12:26, Luis Ferro <[hidden email]> wrote:

Method reorder adds noise to the source control, by marking changes where no change occurred (similar to white space changes from tab / spaces and elimination of end of line spaces).

Noise is bad.
LF


On 2013/07/27 09:23, Matus Zeman wrote:
I use combination of method grouping and ordering (of groups).
First goes PHP "__" methods like: __construct, __toString, ...
Second methods forced by interfaces.
Then other methods where I try to keep related methods together.
Last are getters/setters.

I don't think ordering of methods should be forced into coding standard but it might be considered as a recommendation - but please nothing like alpha ordering where you'll spend more time keeping the order right than coding useful stuff.

Regards,
Matus


On 27 July 2013 15:09, Frank Brückner <[hidden email]> wrote:
Hi Corentin,
my opinion:

1. This is a job for your IDE.
2. There are more important tasks than this. (e.g. bugs, missing documentation, …)


Kind regards,
Frank


Am 27.07.2013, 09:34 Uhr, schrieb Corentin Larose <[hidden email]>:


Hello eveyone,

I would like to propose a Coding Standard (or convention) for the
methods order in a class.

- Since there is no real trivial order to respect, you can often observe
two adapters having the same methods in a different order.

- Since we most often use IDEs, we have a methods list somewhere which
we are able to class more or less the way we want.

It seems that ordering methods in a class by alpha order is the only
trivial/consensual possibility (often used also in css).

Some special pre order could happen for
static/private/protected/public/magic methods, even if I'm not sure if
it would be very interesting.

Intended goal would be to be able to put a new method in a class without
wondering each time where.

What do you think ?

Regards,

Corentin Larose - Paris

CTO & Co-founder @ QAPA



Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Marco Pivetta
@Martin yes, that was suggested, and we discussed it on Wednesday during the talk we had about what is going on zf3 ( https://www.youtube.com/watch?feature=player_detailpage&v=loJeotcIAE4#t=1726 )

The problem is that it requires quite an effort, and obviously would collide with all current pull requests, as well as making merging fixes between ZF3 and ZF2 harder.



On 8 November 2013 13:38, Martin Keckeis <[hidden email]> wrote:
Hello together,

as the ZF2 components can now be installed independently, wouldn't it make sense that also the unitTests get seperated? So when only e.g. Zend\Filter is installed, testing is also possible.

(maybe this was already suggested, but i couldn't find)


2013/7/27 Marco Pivetta <[hidden email]>

@bas those changes are ok only when the PR queue is empty and a complete rewrite happens. As luis said, they just introduce problems.

On 27 Jul 2013 12:43, "Bas Kamer" <[hidden email]> wrote:
But surely correct formatting is a good thing. When is a good time to add those kind of 'non' changes?

When code is change anyway. Or in a separate commit/pr? Or not at all? I tend to mix them into code changes when I see a discrepancy or in separate commits, usually after the CI failed due to the pho-cs-fixer check.


On 27 jul. 2013, at 12:26, Luis Ferro <[hidden email]> wrote:

Method reorder adds noise to the source control, by marking changes where no change occurred (similar to white space changes from tab / spaces and elimination of end of line spaces).

Noise is bad.
LF


On 2013/07/27 09:23, Matus Zeman wrote:
I use combination of method grouping and ordering (of groups).
First goes PHP "__" methods like: __construct, __toString, ...
Second methods forced by interfaces.
Then other methods where I try to keep related methods together.
Last are getters/setters.

I don't think ordering of methods should be forced into coding standard but it might be considered as a recommendation - but please nothing like alpha ordering where you'll spend more time keeping the order right than coding useful stuff.

Regards,
Matus


On 27 July 2013 15:09, Frank Brückner <[hidden email]> wrote:
Hi Corentin,
my opinion:

1. This is a job for your IDE.
2. There are more important tasks than this. (e.g. bugs, missing documentation, …)


Kind regards,
Frank


Am 27.07.2013, 09:34 Uhr, schrieb Corentin Larose <[hidden email]>:


Hello eveyone,

I would like to propose a Coding Standard (or convention) for the
methods order in a class.

- Since there is no real trivial order to respect, you can often observe
two adapters having the same methods in a different order.

- Since we most often use IDEs, we have a methods list somewhere which
we are able to class more or less the way we want.

It seems that ordering methods in a class by alpha order is the only
trivial/consensual possibility (often used also in css).

Some special pre order could happen for
static/private/protected/public/magic methods, even if I'm not sure if
it would be very interesting.

Intended goal would be to be able to put a new method in a class without
wondering each time where.

What do you think ?

Regards,

Corentin Larose - Paris

CTO & Co-founder @ QAPA




Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

ThaDafinser
Hello together,

good would be also, when the Zend\View\Helper\* are seperated to their real Zend\* component. Like it's done already for many components like Zend\Form\View\Helper\....

Examples which should be moved:
* Zend\View\Helper\PaginationControl
* Zend\View\Helper\Navigation\*




2013/11/8 Marco Pivetta <[hidden email]>
@Martin yes, that was suggested, and we discussed it on Wednesday during the talk we had about what is going on zf3 ( https://www.youtube.com/watch?feature=player_detailpage&v=loJeotcIAE4#t=1726 )

The problem is that it requires quite an effort, and obviously would collide with all current pull requests, as well as making merging fixes between ZF3 and ZF2 harder.
On 8 November 2013 13:38, Martin Keckeis <[hidden email]> wrote:
Hello together,

as the ZF2 components can now be installed independently, wouldn't it make sense that also the unitTests get seperated? So when only e.g. Zend\Filter is installed, testing is also possible.

(maybe this was already suggested, but i couldn't find)


2013/7/27 Marco Pivetta <[hidden email]>

@bas those changes are ok only when the PR queue is empty and a complete rewrite happens. As luis said, they just introduce problems.

On 27 Jul 2013 12:43, "Bas Kamer" <[hidden email]> wrote:
But surely correct formatting is a good thing. When is a good time to add those kind of 'non' changes?

When code is change anyway. Or in a separate commit/pr? Or not at all? I tend to mix them into code changes when I see a discrepancy or in separate commits, usually after the CI failed due to the pho-cs-fixer check.


On 27 jul. 2013, at 12:26, Luis Ferro <[hidden email]> wrote:

Method reorder adds noise to the source control, by marking changes where no change occurred (similar to white space changes from tab / spaces and elimination of end of line spaces).

Noise is bad.
LF


On 2013/07/27 09:23, Matus Zeman wrote:
I use combination of method grouping and ordering (of groups).
First goes PHP "__" methods like: __construct, __toString, ...
Second methods forced by interfaces.
Then other methods where I try to keep related methods together.
Last are getters/setters.

I don't think ordering of methods should be forced into coding standard but it might be considered as a recommendation - but please nothing like alpha ordering where you'll spend more time keeping the order right than coding useful stuff.

Regards,
Matus


On 27 July 2013 15:09, Frank Brückner <[hidden email]> wrote:
Hi Corentin,
my opinion:

1. This is a job for your IDE.
2. There are more important tasks than this. (e.g. bugs, missing documentation, …)


Kind regards,
Frank


Am 27.07.2013, 09:34 Uhr, schrieb Corentin Larose <[hidden email]>:


Hello eveyone,

I would like to propose a Coding Standard (or convention) for the
methods order in a class.

- Since there is no real trivial order to respect, you can often observe
two adapters having the same methods in a different order.

- Since we most often use IDEs, we have a methods list somewhere which
we are able to class more or less the way we want.

It seems that ordering methods in a class by alpha order is the only
trivial/consensual possibility (often used also in css).

Some special pre order could happen for
static/private/protected/public/magic methods, even if I'm not sure if
it would be very interesting.

Intended goal would be to be able to put a new method in a class without
wondering each time where.

What do you think ?

Regards,

Corentin Larose - Paris

CTO & Co-founder @ QAPA





Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Wesley Overdijk
+1. That would a very good thing to do. When dashing through the code, I sometimes find myself wondering where the view helpers went.

Met vriendelijke groet / Kind regards,

Roberto Wesley Overdijk

@RWOverdijk
M. +31 (0)6  15553243
                      _
                     / \
                     \\ \
             .-""-.   \\ '-.
           /` -.   '._/   o '.
         {`     \            /
          \     /  (   `;'-'`
           '.  '--.-'-._ '-.
             `-----`    `'--`

On Nov 18, 2013, at 8:20 AM, Martin Keckeis <[hidden email]> wrote:

Hello together,

good would be also, when the Zend\View\Helper\* are seperated to their real Zend\* component. Like it's done already for many components like Zend\Form\View\Helper\....

Examples which should be moved:
* Zend\View\Helper\PaginationControl
* Zend\View\Helper\Navigation\*




2013/11/8 Marco Pivetta <[hidden email]>
@Martin yes, that was suggested, and we discussed it on Wednesday during the talk we had about what is going on zf3 ( https://www.youtube.com/watch?feature=player_detailpage&v=loJeotcIAE4#t=1726 )

The problem is that it requires quite an effort, and obviously would collide with all current pull requests, as well as making merging fixes between ZF3 and ZF2 harder.
On 8 November 2013 13:38, Martin Keckeis <[hidden email]> wrote:
Hello together,

as the ZF2 components can now be installed independently, wouldn't it make sense that also the unitTests get seperated? So when only e.g. Zend\Filter is installed, testing is also possible.

(maybe this was already suggested, but i couldn't find)


2013/7/27 Marco Pivetta <[hidden email]>

@bas those changes are ok only when the PR queue is empty and a complete rewrite happens. As luis said, they just introduce problems.

On 27 Jul 2013 12:43, "Bas Kamer" <[hidden email]> wrote:
But surely correct formatting is a good thing. When is a good time to add those kind of 'non' changes?

When code is change anyway. Or in a separate commit/pr? Or not at all? I tend to mix them into code changes when I see a discrepancy or in separate commits, usually after the CI failed due to the pho-cs-fixer check.


On 27 jul. 2013, at 12:26, Luis Ferro <[hidden email]> wrote:

Method reorder adds noise to the source control, by marking changes where no change occurred (similar to white space changes from tab / spaces and elimination of end of line spaces).

Noise is bad.
LF


On 2013/07/27 09:23, Matus Zeman wrote:
I use combination of method grouping and ordering (of groups).
First goes PHP "__" methods like: __construct, __toString, ...
Second methods forced by interfaces.
Then other methods where I try to keep related methods together.
Last are getters/setters.

I don't think ordering of methods should be forced into coding standard but it might be considered as a recommendation - but please nothing like alpha ordering where you'll spend more time keeping the order right than coding useful stuff.

Regards,
Matus


On 27 July 2013 15:09, Frank Brückner <[hidden email]> wrote:
Hi Corentin,
my opinion:

1. This is a job for your IDE.
2. There are more important tasks than this. (e.g. bugs, missing documentation, …)


Kind regards,
Frank


Am 27.07.2013, 09:34 Uhr, schrieb Corentin Larose <[hidden email]>:


Hello eveyone,

I would like to propose a Coding Standard (or convention) for the
methods order in a class.

- Since there is no real trivial order to respect, you can often observe
two adapters having the same methods in a different order.

- Since we most often use IDEs, we have a methods list somewhere which
we are able to class more or less the way we want.

It seems that ordering methods in a class by alpha order is the only
trivial/consensual possibility (often used also in css).

Some special pre order could happen for
static/private/protected/public/magic methods, even if I'm not sure if
it would be very interesting.

Intended goal would be to be able to put a new method in a class without
wondering each time where.

What do you think ?

Regards,

Corentin Larose - Paris

CTO & Co-founder @ QAPA






Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Artur Bodera

​View helpers are provided by respective components (which makes sense given their responsibilities and coupling with parent), so they'll never live all in Zend\View\Helper\*
Reply | Threaded
Open this post in threaded view
|

Re: Starting the 3.0 branch

Oliver Koenig
This post has NOT been accepted by the mailing list yet.
In reply to this post by EvanDotPro
Hi everyone,

sorry, if I repeat something that was mentioned already, but I find it important enough that it can't be repeated too often.
I'm a ZF2 newbie, btw, and just browsing the ZF2 framework core code in order to understand how it works. It's tedious, and I regularly come across some points that I would like to mention.

The code quality, please improve the quality, remove inconsistencies in naming, remove hidden dependencies, clear and clean up code that is hard to follow.

Example: ZF 2.2.5
Zend\Mvc\Service\ModuleManagerFactory:
    public function createService(ServiceLocatorInterface $serviceLocator)
    {
        if (!$serviceLocator->has('ServiceListener')) {
            $serviceLocator->setFactory('ServiceListener', 'Zend\Mvc\Service\ServiceListenerFactory');
        }
    ...
    }
ServiceLocatorInterface doesn't have a declared function setFactory(), it is only thanks to PHP that it will find the function if the implementing class defines it or has a __invoke defined that handles it.
But ordinary human programmers will rack their brains to understand the code when they browse through it.
It is really very difficult to understand the ZF2 system, and such code doesn't make it easier.
It would be really very nice if the code would become a bit easier to follow through for someone who is not a core ZF2 developer.

Cheers,
Oliver

12345