|
| From: | Sheldon Gill |
| Subject: | Re: GNUstep Coding Standard Additions |
| Date: | Tue, 03 May 2005 10:08:59 +0800 |
| User-agent: | Mozilla Thunderbird 1.0 (Windows/20041206) |
Richard Frith-Macdonald wrote:
So your recommendation is static NSString * BundleObjectName(NSString *path, NSString* executable) over static NSString * bundle_object_name(NSString *path, NSString* executable) in this module private case?Actually, my recommendation is to not force people to a single style when contributing. However, our standard style would be without underscores (ie the one used generally because it *has* to be used for the public api). I think function names usually have a lowercase initial letter if they don't have the NS or GS prefix though.
You see? You're not certain about the initial letter. Someone who has been contributing substantial amounts of code for years.
This is a big part of the issues I'm trying to raise and address. You say "our standard style" but my point is that both styles are used and there is nothing in the 'Standard'.
You note its "generally used". Not universally used. The reason being there are choices here. I'm advocated establishing clear rules for the 'Standard' for everyone to follow.
That said, I am *not* advocating using those rules as a strict patch filter. I'm not recommending we force contributors to comply. I am rather advocating defining rules for the 'Standard' which maintainers will comply with.
I'm not saying we then try an force maintainers to go to the source and immediately revise everything to comply, either. Once everyone maintaining knows the rules the code base will move towards compliance. If someone gets all enthusiastic thats fine. Otherwise it'll take some time. I'm fine with that, too.
I think we should also be clear that "dictionary" or "dict" is preferred over "d". Except for mathematical function implementations single or double character identifiers are a bad idea.I think the rule is that variables should be clear, readable, and not misleading ... so it depends a lot on context. In general, shorter is better as long as it's very obvious what the variable is ... so if a variables's scope is larger (many lines), it needs to be longer and more descriptive.I disagree that in general, shorter is better. In my view, more apparent and descriptive is always better than terse or cryptic. Trying to work with legacy C code taught me that in spades.My point was/is that, very often shorter == more apparent and longer/more-descriptive is less apparent/readable ... it varies with circumstances ... so I think it's not an area that can be reasonably ruled upon. The aim is to make things clear/readable. I'm not advocating terse and cryptic any more than you are advocating verbose and obfuscated.
Fine. We're mostly agreed. I'm just really against single letter identifiers for the non-mathematical case. Always. That was really the point that I was making, even if I wasn't so clear about it.
As I said, both are used internally and I think that situation is bad. Thus, we should pick the "one true style" for this as part of the canon.Can we agree that *one* method is better than two?Yes ... but I don't think it's sufficiently better that one should be insisted upon when people contribute. I think that the NeXT style is overwhelmingly more common, so I prefer it, and it's no real trouble to convert gnu-style function names to NeXT style ones.
Ahah!Take a look at what you wrote. I take it that you're saying that the NeXT style is the standard and gnu_style_function names should be changed to comply. Isn't that so?
Well in this we differ. For code to be readily readable by everyone I'd say that:if (cond) { <body> } is every bit as readable as: if (cond) { <body> }Fundamentally yes, but people get used to particular styles and then find the alternatives unclear. There are also cases (mostly misuse of spaces) which I consider fundamentally difficult to read,and others apparently do not, so perhaps tghey are habit too... if( cond ){ <body>}
Blech! I don't like that one, either.
Sorting out discrepancies and establishing rules is more important from a software engineering view point than a simple question of readability.The two are inseparable imo. Readability is a major factor in determining rules.
Yes it is. The rules, though, are about more than readability. (ie readability is a sub-set of software engineering)
In writing code to be contributed I encountered these situations where [snip]I don't know about individual instances ... but generally when reviewing patches I modify them to conform to our standards, and I guess I also modify to conform to our general practices (eg names are NeXT style almost everywhere, even if we don't formally say so in the standards).
Yes and I'm not trying to fault you for making the changes. You've decided in your own mind that that the NeXT style is the way. Others haven't. We don't have a decision. Let us collaboratively decide so that we are being consistent and clear.
[snip]Hence, I think we can have a "No tabs" rule and put zero noses out of joint.Probably ... I just worry about alienating possible contributors ... we need all the new people we can get. I think someone else in this thread suggested 'guidelines' rather than 'standards'.
You're referring to David's post. He also said "I believe that better specification of coding standards is a good thing." ;)
I also have no wish to alienate possible contributors. That isn't what this is about at all, as I said earlier
Basically, I think of 'standards' as the minimal set of rules to be fairly sure that as contributed patch can be applied then read/understood reasonably efficiently (if a patch does not meet these standards, then trying to review it might be more trouble than the patch is worth), wheras 'guidelines' might tell peopole how we would like things in an ideal world.
What about the internal case, as opposed to a contributed patch? (ie direct CVS commits)
I look at the Coding Standard first and foremost as a document for internal use.
Regards, Sheldon
| [Prev in Thread] | Current Thread | [Next in Thread] |