User: Password:
|
|
Subscribe / Log in / New account

Getting the right kind of contributions

Getting the right kind of contributions

Posted May 29, 2008 9:58 UTC (Thu) by roc (subscriber, #30627)
Parent article: Getting the right kind of contributions

We obviously need a programming language in which there is only one valid way to write a given
sequence of tokens, and all other inputs generate compiler errors.


(Log in to post comments)

Getting the right kind of contributions

Posted May 29, 2008 14:44 UTC (Thu) by dlang (subscriber, #313) [Link]

who's preferred layout would everyone agree to use?

Python is trying to do this, but while people who like it tend to really love it, many others
dispise it for the same reasons.

Getting the right kind of contributions

Posted May 29, 2008 20:03 UTC (Thu) by cpeterso (guest, #305) [Link]

Linux already has an "official" CodyingStyle (including indent configuration) and a checkpatch
script. Perhaps every checkin must be run through indent before acceptance. And to get
everyone up to date with the same baseline indent style, have a flag day where Linus' git tree
gets indented (to fix any currently offending files).

Getting the right kind of contributions

Posted May 29, 2008 20:26 UTC (Thu) by dlang (subscriber, #313) [Link]

the initial post was suggesting that someone write a language that enforced the coding style
so that any deviations would result in a compile-time error.

that's a far cry from the kernel coding style document (which by the way, is a guideline, not
a hard requirement. see the flame-wars over checkpatch)

the problem with a flag-day reformat is that it will break everyone's patches that haven't
been merged yet.

the only possible exception to this is Ted suggested doing a flag-day whitespace cleanup, and
modify tools to ignore whitespace changes on the - lines of patches to avoid this
incompatibility.

but other reformatting needs to include a judgement call, not just mechanical formatting

Getting the right kind of contributions

Posted May 29, 2008 21:46 UTC (Thu) by broonie (subscriber, #7078) [Link]

That's actually one of the problems in some areas - patches get knocked back due to violating
CodingStyle but being consistent with the rest of the file they touch. Without going through
and improving the entire file the patch introduces another form of bad practice.

Smarter Diff

Posted May 29, 2008 14:52 UTC (Thu) by fmyhr (subscriber, #14803) [Link]

It seems to me that what is needed is a smarter diff tool - one that parses the code the same
way the precompiler and compiler do, and doesn't bother us poor humans with the noise
generated by simple whitespace changes.

Smarter Diff

Posted May 29, 2008 14:59 UTC (Thu) by nix (subscriber, #2304) [Link]

Yeah, but how do you apply patches in the presence of intervening 
whitespace changes? A `smarter patch' in that sense would need to have a 
language-specific understanding of indentation, at the *very* least...

Smarter Diff

Posted May 29, 2008 15:57 UTC (Thu) by tjc (guest, #137) [Link]

I don't think this would be a problem in C, since indentation doesn't have semantic meaning.

Smarter Diff

Posted May 29, 2008 16:49 UTC (Thu) by nix (subscriber, #2304) [Link]

Try geting in after someone has de-K&Red your project and applying a patch 
generated earlier, and oopsy. Any line-based patch system would be 
confused if { and } had moved from lines with code on them to lines 
without, or vice versa.


Smarter Diff

Posted May 29, 2008 16:56 UTC (Thu) by fmyhr (subscriber, #14803) [Link]

Maybe keep stupid patch (line-by-line) but have smart diff that understands the language and
parses by tokens not lines? Patchfiles would still be noisy, but humans would ignore that and
look at output of smart diff to see what had really changed.

Smarter Diff

Posted May 29, 2008 16:59 UTC (Thu) by fmyhr (subscriber, #14803) [Link]

But that doesn't fix your pre- and post- de-K&R problem does it? Patch would have to be smart
(token, not line-based) too.

Smarter Diff

Posted May 29, 2008 19:41 UTC (Thu) by tjc (guest, #137) [Link]

Yeah, a line-based patch system wouldn't work in that case.  But I think lexically scanning
the input would be sufficient -- you wouldn't have to parse it.  If two files generate the
same sequence of tokens, then I think they could be considered equivalent in a "free form"
language.

Getting the right kind of contributions

Posted May 30, 2008 1:23 UTC (Fri) by pr1268 (subscriber, #24648) [Link]

We obviously need a programming language in which there is only one valid way to write a given sequence of tokens, and all other inputs generate compiler errors.

Such a language already exists: RPG. Just don't expect to see much Linux kernel development in it anytime soon!

<sarcasm>

Here's yet another (audacious) proposal: Let's get rid of whitespace altogether (except, of course, those spaces required by the C language, i.e., after type declarations, or those in string literals). This would mean one unified coding standard which would not be subject to debate.

Pray that the whitespace-free code works right, because debugging and modifying it would be a real nightmare!

</sarcasm>

Getting the right kind of contributions

Posted May 31, 2008 23:59 UTC (Sat) by csawtell (guest, #986) [Link]

Although you have marked it "sarcasm" this is the most sensible suggestion I have seen during this whole debate about source code formatting. C code expressed in white-space free format could be used as the Standard C Code Interchange and 'Difference & Patch' Format for the Linux Kernel. Programs to convert between the unformatted - Interchange - format and the many formats desired by the Kernel contributers could be created as required. The Wikipedia pretty print and code beautifier has some examples.


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds