Le 10 juil. 2011 à 19:42, David Chisnall a écrit : > On 8 Jul 2011, at 19:53, Quentin Mathé wrote: > >> It's was more about readability. A space before the * makes it stands out in >> a more clear way. > > Standing out is not what we want - we want it to be associated with the thing > it applies to.
It depends. In many cases, we have a tension between putting the emphasis on the 'semantic' or the 'readability', and it's not easy to sort out the best choice. I think there is no best choice that can be picked, because it depends on how each person perceives the code (its reading habit, its vision quality, etc.) My personal bias is to always almost favor readability. I have a poor vision ;-) >> Nicolas suggested we use Foo* rather than Foo * precisely for this reason. I >> rather like the idea, but it decreases readability too much imo. Especially >> arguments looks less readable in methods declarations. >> >> - (NSArray*) emailsForMailbox: (CDCMailbox*)theMailbox; >> >> vs >> >> - (NSArray *) emailsForMailbox: (CDCMailbox *)theMailbox; > > Do we use the latter form? Yes, this except is taken from the guidelines. > I've never used that anywhere, and the last version of the coding guidelines > I looked at said explicitly not to do that because (drumroll) the * was an > attribute of the type and should be next to the type. See the Variable Declaration section in http://etoileos.com/dev/codingstyle/ I think the * as an attribute of the type was a discussion we had at some point, but it isn't in the guidelines unless I overlook some paragraph that contradicts the Variable Declaration section. >> The most problematic point behind your suggestion is that it would imply >> that the code would become really inconsistent everywhere. Given the coding >> guidelines are already applied pretty loosely throughout our codebase, the >> situation would become even worse. >> This puts aside we should revise some more minor points (e.g. ChangeLog, >> Project Layout) in our coding guidelines I agree. > > With regard to ChangeLogs, I'd like to replace this with an ANNOUNCE or NEWS > file for each project. The way I've done it in libobjc2 seems to work well: > > Each commit gets a commit log entry. > Major changes get a bullet point in the ANNOUNCE file. > Before each release, ANNOUNCE is copied to ANNOUNCE.{version} > After each release, ANNOUNCE is reset. > > Duplicating commit log entries in the change log is a bit pointless, but > having a list of new features for each release is useful because it means > that we have something to tell users with each release, without having to go > through the changes and find out what is important and what is just a trivial > bug fix or tweak. Sounds good. In addition, I'd like to have a separate NEWS file to list the new features version by version in a single place. It's easier than having to search the various ANNOUNCE files, and helps to create a basic revision history in the generated API doc. For the releases until now, I used such a NEWS file. Also DocGenerator will turn README, INSTALL and NEWS into the Presentation, Installation and Revision History sections in the sidebar. See http://etoileos.com/dev/api/EtoileFoundation/NEWS.html That's customizable per project though if this menu layout is undesirable in some cases, or some files are not available. > While we're updating stuff, I just checked and we don't have anything saying > not to use the dot syntax for properties, which I seem to recall that we > agreed to avoid at the hackathon ages ago. I'd like to add something saying > that we should favour the use of synthesized properties over explicit > accessors (because they're harder to get wrong and make the code portable to > ARC or GC without code modifications), but that we should avoid the dot > syntax because it hides the semantics of the operation. Agreed. Cheers, Quentin. _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
