On Fri, Apr 25, 2008 at 1:04 AM, Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote: > Hi Wade.Stuart, > > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-04-25 00:30]: > > > > Aristotle Pagaltzis <[EMAIL PROTECTED]> wrote on 04/24/2008 12:32:12 PM: > >> * Jonathan Rockway <[EMAIL PROTECTED]> [2008-04-24 19:10]: > >>> * On Thu, Apr 24 2008, Aristotle Pagaltzis wrote: > >>>> * Jonathan Rockway <[EMAIL PROTECTED]> [2008-04-24 11:25]: > >>>>> * On Thu, Apr 24 2008, Jon Schutz wrote: > >>>>>> No problems, if that's what the Catalyst standard says; I > >>>>>> must have missed it. Where is it? I'd like to consult it > >>>>>> on a number of matters... please post the link. > >>>>> > >>>>> Basically it's more of a "zeitgeist" than an actual > >>>>> document. There are some things that the community has > >>>>> decided and "just do". > >>>> > >>>> That?s the sort of feel-good bollocks I?d expect to read on > >>>> a Rails hype blog, not here. Unspoken rules and gut feel are > >>>> no way to run a community. Catalyst suffers from this in > >>>> general: way too little is written down, much less in any > >>>> systematic fashion. > >>> > >>> Nobody has time to run a bureaucracy. We just want to write > >>> code. > >> > >> Yes, backcompat code. And I suppose the time to run a > >> deprecation cycle bureaucracy will find itself. File under > >> ?false laziness.? > > > > If you expect behavior over cycles, write test code. If > > changes happen that make that test fail it will prompt > > discussion and offset the depreciation cycle to the closest > > change set. If you want to document down to the dot, without > > test code -- you are in for a world of outdated documentation. > > I am not even talking about code docs here, I am talking about a > short note about the project's conventions. Something like the > `Documentation/CodingStyle` document in the Linux kernel source, > except appropriately scaled down since Catalyst is so much > smaller in terms of both SLoC and contributor count. > > It doesn't have anything to do with bureaucracy, I'm talking > about one, maybe two pages of bullet points about the most > important guidelines of the project. "Methods without docs are to > be considered internal," "leading underscore in a documented > method name means it's OK for subclasses to touch but not > outsiders," "all patches must be accompanied by tests" etc etc, > that sort of thing. Not a law code, just a summary of how things > are done 'round here. In fact it *mustn't* be too elaborate and > intricate, else it won't get read.
I've put those points at http://catwiki.toeat.com/source_code/Coding_conventions -- Zbigniew Lukasiak http://perlalchemy.blogspot.com/ _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/