(in line) 2015-12-21 11:22 GMT+01:00 Raquel Pau Fernández <[email protected]>: > 1) Ok, no problem, but I think that code style is really related with static > analysis tools, because these tool will be able to validate or fix your code > style.
+1000. We need rules and guidelines, and "something" to validate/check it. It is not productive to discuss the same things with the same persons. > 2) I understand that you need to validate exactly what are your conventions > before setting them as part of your project. After that, your trust in the > tool like you trust in code editors. > > 3) I have readed the suggested PR you send me, but I can't completely > understand yet. XStream, as far as I know, uses the readResolve when it is > dealing with the ObjectOutputStream and according the official Java > documentation, just Serialiable and Externalizable elements can use > readResolve. So, I don't understand why those classes that contain > readResolve do not implement Serializable. Anyway, these are the Jenkins > conventions/code style :-) and it is what I think that should be defined in > somewhere. > > > > El lunes, 21 de diciembre de 2015, 10:25:09 (UTC+1), Kanstantsin Shautsou > escribió: >> >> I hope keep this thread as it named in topic and don’t touch static >> analysing. >> >> PS. You can’t blindly trust to static analysing results, they are only >> helpers and should never be used in autofix mode. Example of Serialisation >> fix attempt https://github.com/jenkinsci/jenkins/pull/1945 >> >> >> >> On Dec 21, 2015, at 12:19, Raquel Pau Fernández <[email protected]> wrote: >> >> Thank you for your opinion, >> >> However, If you think is that this PR is not valid for the Serialization, >> I am creating a convention that automatically makes classes to implement >> Serializable if contains readResolve. In fact, the problem that walkmod >> address is autofixing issues that appear over and over again. External >> people, like me, can do the same error manually and, in my opinion, if >> conventions are explicitly defined, these kind of errors can be >> automatically fixed. >> >> FindBugs reports issues, but does not fix them. The result of this PR is >> produced by Walkmod, not by me. Walkmod autofix bad practices because you >> are automatizing these kind of corrections and thus, saves time. >> >> >> El lunes, 21 de diciembre de 2015, 10:07:43 (UTC+1), Kanstantsin Shautsou >> escribió: >>> >>> Sorry, but imho this PR kills code. Will be glad to hear why jenkins >>> should add walkmod that i never saw in any projects instead of mass used >>> checkstyle (this thread is about styling). Modified parts (Serializable, >>> readResolve()) in PR reportable by FindBugs that is static analysing tool. >>> >>> On Dec 21, 2015, at 11:56, Raquel Pau Fernández <[email protected]> >>> wrote: >>> >>> Hi to everyone, >>> >>> I have created an open source tool called Walkmod for this purpose (link >>> - http://www.walkmod.com). In fact, I executed Walkmod into Jenkins (core >>> module) to remove dead code. This PR contains the results >>> https://github.com/jenkinsci/jenkins/pull/1957. >>> >>> Walkmod allows you define your code conventions and fixes the code. It is >>> possible because code conventions are implemented as code transformations. >>> After all code transformations are executed, Walkmod writes the file using >>> an specific Eclipse formatter or just modifying the original source file >>> with the minimum semantic or syntactic changes (e.g add @Override). >>> >>> Moreover, there is a service called walkmodhub whose purpose is to >>> execute walkmod incrementally for each push. Then, walkmod sends a PR with >>> the necessary changes and nobody needs to change their habits. >>> >>> Let me know your opinions. >>> >>> Raquel >>> >>> >>> El martes, 10 de noviembre de 2015, 22:38:33 (UTC+1), Stephen Connolly >>> escribió: >>>> >>>> On 10 November 2015 at 21:34, Jesse Glick <[email protected]> wrote: >>>>> >>>>> On Tue, Nov 10, 2015 at 3:22 PM, Stephen Connolly >>>>> <[email protected]> wrote: >>>>> > None of those match "Jesse"-style so hopefully we can kill that >>>>> > abomination off ;-) >>>>> >>>>> CheckStyle is a syntactic, not semantic, processor so it cannot >>>>> distinguish between adjectival annotations, determiners, and type >>>>> qualifiers. >>>>> >>>> >>>> Which is why we should put annotations on the line(s) before the >>>> method/field declaration >>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Jenkins Developers" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2QF7BgnazAaf6w2p_N2Fcu5bGoGgvSFbQUo9DSdsvpxQ%40mail.gmail.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "Jenkins Developers" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/jenkinsci-dev/8fjvXGYbFJ4/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jenkinsci-dev/33067c26-6b0a-482c-9523-a723e0518adb%40googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Jenkins Developers" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/jenkinsci-dev/8fjvXGYbFJ4/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/8326ef25-1a2e-47c2-b00e-3f7053a7a49f%40googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> >> > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/abf1c0d0-f627-42af-8409-335ff0888831%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- Manuel Recena Soto * manuelrecena.com [/blog] * linkedin.com/in/recena -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CABa-UofJ%3DujW7ov6GG2LNdeSFnAGkf7SUpownaoWaO1sfJ73wA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
