Re: Open source C# namespace to convert many audio formats
From: Daniel O'Connell [C# MVP] (onyxkirx_at_--NOSPAM--comcast.net)
Date: 09/20/04
- Next message: Brian Henry: "Re: 2003 vs 2005B"
- Previous message: Ignacio Machin \( .NET/ C# MVP \): "Re: Is there a way to calculate BIG numbers expressed as strings?"
- In reply to: gilad: "Re: Open source C# namespace to convert many audio formats"
- Next in thread: gilad: "RE: Open source C# namespace to convert many audio formats"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 20 Sep 2004 13:04:54 -0500
"gilad" <gilad@discussions.microsoft.com> wrote in message
news:8FE33174-B74A-4B54-941A-95C2072FE547@microsoft.com...
> "Daniel O'Connell [C# MVP]" wrote:
>
>> I will say you probably will not get away with it. Personally I would
>> *not*
>> use your library simply because its naming conventions are so at odds
>> with
>> those I am used to. It makes the library seem written by someone who
>> does'nt
>> know what he's doing.
>
> But if you were a programmer who seriously needed the functionality of the
> library, would you still balk at the style? It doesn't seem likely. You'd
Not if it was vital, though I would probably fire off a courtesy email to
the maintainer suggesting he learns proper naming conventions.
However, except in the rare case that a library is the only available that
supports something, I certainly would turn it down in favor of a competitor
that followed conventions.
> probably shrug your shoulders and shake your head, and use it. And as for
> it
> having the appearance of being "written by someone who does'nt know what
> he's doing", isn't the actual code logic going to tell this rather than
> the
> style? If I'm doing everything correctly as far as interfacing the DLLs,
> construction of objects, etc, and yet decide to use a slightly different
> naming convention (because it is style we're talking about here isn't
> it?),
> doesn't that say whether or not I "know what I'm doing"? Breaking a style
> convention could also be considered being a 'rebel'.
>
It could be considered a rebellion, but more times than not its simply
"Damn, this guy didn't even bother reading the most basic document". If you
couldn't be bothered to read a styles document, why should I think you took
the time to learn initalization, property, and event patterns?
For the record, I know you have read it, but that is the appearance that is
often taken from code that is not named along with standard style.
>> While I understand you are used to perl's naming conventions, those *are*
>> perl's naming conventions and are not a very good choice in a platform
>> that
>> doesn't use them.
>
> Like I said, I was influenced by this style convention, not using it
> explicitly. And I have alternated the Perl style in my own projects when
> it
> suited me. Only when I have submitted to a repository like CPAN have I
> conformed entirely. (Largely because the hue and cry that rang out from
> there
> when I didn't.)
>
Within your own code, its one thing, but for open source projects
especially, you should look into using standard conventions. 90%+ of users
are going to expect those conventions, meaning some potential contributers
aren't going to contribute due to style alone(if its bad enough, I won't
even bother tryign to dechiper it).
>> Anyway, while I can see you're worried about shift key, a good number of
>> characters you have to use commonly in C# code require shift, inclufing
>> _.
>> Whats the difference in typing
>>
>> something_else and somethingElse? Same number of shift presses, after
>> all.
>
> You got me there. I do use underscores. But I only do it where I need to
> separate words for clarity (what I consider clarity anyway), so a lot of
> my
> variables were pretty short and without the underscore (which seems to
> draw a
> lot of criticism too; see below). The convention of C# uses long names
> most
> times, and at least have one shift operation for every named thing.
>
One of the many code clarity guidelines: Use variables that mean something.
LOL. Its just an expectation of good code.
Personally, I use short, but complete variable names. When I'm dealing with
just one array or somesuch, I will use just
int index;
or
int count; (depending). But if the method has a couple of indexers or loops,
I'll do
int charIndex;
int stringIndex;
int charCount;
int stringCount;
or what have you.
Parameters should be fairly clear, but I don't think they should be too
long. XML docs should be the primary source of information about a
parameter, not its name.
>> You classes should be clearer too, ;). Avoid using abbreviations when you
>> can avoid it.
>
> Sigh. I like abbreviations. So short, so succinct... Okay, thanks for the
> comments.
Yes, very short...but when I don't know what they mean, they become a
difficult issue for me. So using abbreviations for uncommon terms is a bad
idea. You have to remember that your user isn't going to know everything
about audio and they do not want to have to refer back to docments every
time they run across an abbreviation they don't know off hand.
- Next message: Brian Henry: "Re: 2003 vs 2005B"
- Previous message: Ignacio Machin \( .NET/ C# MVP \): "Re: Is there a way to calculate BIG numbers expressed as strings?"
- In reply to: gilad: "Re: Open source C# namespace to convert many audio formats"
- Next in thread: gilad: "RE: Open source C# namespace to convert many audio formats"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
