Re: staging: ks7010: Rename jump labels
>> Would you like to support the renaming of a label like "error_out1" >> (in the function "ks7010_upload_firmware" for example)? > > They should be renamed too. Anything using numbers instead of explicit Interesting … > Anything using numbers instead of explicit labels should be updated. Would you dare to search for corresponding update candidates explicitly by special semantic patch scripts? > I included the reasons in the patch I just sent, > hopefully the documentation is clearer now. I am curious on how feedback will evolve for your suggestion "CodingStyle: Clarify and complete chapter 7". https://lkml.org/lkml/2016/7/25/207 How do you think about to show a shorter label like "free_bar" (instead of "err_free_bar") as an example? >> "Source code review around jump label usage"? >> https://lkml.org/lkml/2015/12/11/378 >> http://article.gmane.org/gmane.linux.kernel/2106190 > > Personally I see no value in such statistics. Do they indicate any code smells eventually? > Either labels are wrong (either wrong indentation or wrong name) > and should be fixed, or they are correct and you should not touch them. Do you find such changes worthwhile (without touching also any surrounding source code)? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: staging: ks7010: Rename jump labels
Hi Markus, On Thu, 21 Jul 2016 22:11:53 +0200, SF Markus Elfring wrote: > >> How do you generally think about jump label renaming? > > > > Renaming from "out0:", "out1:" etc to something meaningful, yes. > > I suggest to take another look at such identifiers. > > Would you like to support the renaming of a label like "error_out1" > (in the function "ks7010_upload_firmware" for example)? They should be renamed too. Anything using numbers instead of explicit labels should be updated. I included the reasons in the patch I just sent, hopefully the documentation is clearer now. > Will the software evolution be continued also with information from the topic > "Source code review around jump label usage"? > https://lkml.org/lkml/2015/12/11/378 > http://article.gmane.org/gmane.linux.kernel/2106190 Personally I see no value in such statistics. Either labels are wrong (either wrong indentation or wrong name) and should be fixed, or they are correct and you should not touch them. Whether the same label name is used somewhere else is irrelevant. Labels are local by nature, so uniqueness isn't a goal at all, only correctness. -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: staging: ks7010: Rename jump labels
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/scripts/checkpatch.pl?id=92d21ac74a9e3c09b0b01c764e530657e4c85c49#n4326 > > "#goto labels aren't indented, allow a single space however" > > Can't be clearer :-) Should such information from a comment in this script be also explicitly mentioned in the document "CodingStyle" anyhow? How should the support for indentation of jump labels with a single space be expressed in all relevant Linux development documentation? >> How do you generally think about jump label renaming? > > Renaming from "out0:", "out1:" etc to something meaningful, yes. I suggest to take another look at such identifiers. Would you like to support the renaming of a label like "error_out1" (in the function "ks7010_upload_firmware" for example)? > Did you have anything else in mind? Not really for this update suggestion. Will the software evolution be continued also with information from the topic "Source code review around jump label usage"? https://lkml.org/lkml/2015/12/11/378 http://article.gmane.org/gmane.linux.kernel/2106190 Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
