Skip to Content.
Sympa Menu

devel - Re: [sympa-developpers] Coding style guidelines

Subject: Developers of Sympa

List archive

Chronological Thread  
  • From: Soji Ikeda <address@concealed>
  • To: Luc Didry <address@concealed>
  • Cc: address@concealed
  • Subject: Re: [sympa-developpers] Coding style guidelines
  • Date: Fri, 25 May 2018 08:00:02 +0900

Hi Luc,

2018/05/25 0:20、Luc Didry <address@concealed>のメール:

> mercredi 23 mai 2018, 17:54:48 CEST IKEDA Soji wrote:
>> Hi Luc,
>>
>> Modeline would be attributed to Guillaume Rousse.
>>
>>
>> The .perltidyrc practically used already exists.
>> See doc/README.perltidy and doc/dot.perltidyrc in source.
>>
>> Past discussions about this file may be found in archives.
>>
>>
>
> Wonderful! We don't even have to discuss about it 🙂
>
> I added a perltidy test in xt/ (Marc explained during the hackathon
> that xt/ test are tests for the developers) that check the src/ folder
> for files and check if they are tidy.
>
> You can see it in https://github.com/sympa-community/sympa/pull/322.

Great!

> I realized that we have no way to install modules needed by the tests
> in the xt folder: they are not in ModDef.pm (and that's good, there is
> no reason for them to be in it), but we needed a simple way to install
> the dev tests dependencies, so I created a simple cpanfile with a
> develop phase.

I feel this seems what we need.

Currently MedDef.pm is used only by sympa_wizard.pl
(and the other project Task::Sympa). I think it is possible that we replace
it with
some generic tool like Carton, and maintain cpanfile.

> Then I created a new branch from the one of my PR to test if we could
> integrate this perltidy test into Travis CI, and it works well (the
> perltidy test can fail without making Travis fail).
> The commit:
> https://github.com/sympa-community/sympa/commit/953da883a0a6989448d5791045114cb3abaeb5c7
> The Travis build:
> https://travis-ci.org/sympa-community/sympa/builds/383240314?utm_source=github_status&utm_medium=notification
>
> For now, it creates too much output in Travis, because we have a lot
> of non tidy code, but since we can now use the travis test to know
> where to clean code and how, we can aim for a fully tidy code base and
> after that, use Travis to detect non tidy changes in the code base.

As I commented on PR, I’m not sure whether testing tidiness using
Perl::Tidy is useful or not. I’ll think about it further in other days.

Thanks for suggestion.


Regards,
— Soji


> --
> Luc
> "La route est longue, mais la voie est libre…" https://framasoft.org
>
> Framasoft ne vit que par vos dons (déductibles des impôts). Merci d'avance
> pour votre soutien https://soutenir.framasoft.org
>
>





Archive powered by MHonArc 2.6.19+.

Top of Page