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.
> 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? 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.
> Hmm, we already write Foo * in variable declarations, arguments and return
> types as the coding guidelines require it. For cast expression, I use the
> same personally.
We use Foo * in declaration (including declarations of function arguments), and
Foo* in cast expressions (including casts of Objective-C methods and returns -
although apparently you don't), so we've got the inconsistency already. It's
not a really major problem though, as long as we all use the new form going
forwards and update to the new version when we modify some existing code
(that's what I've been doing recently with LanguageKit).
> 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.
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.
David
-- Send from my Jacquard Loom
_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss
