Re: Question about return style

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Wed, 28 May 2008 23:36:25 -0700, Jon Skeet [C# MVP] <skeet@xxxxxxxxx> wrote:

[...]
Well, that's an interesting point. Personally I find it worth re-evaluating all
my habits and patterns when approaching a different language.

For me, I find the opposite to be true. While I agree that habits learned elsewhere can sometimes be counter-productive, I've _rarely_ found this to be an issue in practice. But at the same time, I find that trying to essentially start over can be disorienting and time-consuming. Time-consuming I can live with if it's really important, but here not only do I not personally find it that important, being able to shift into a new language, especially when I am still coding in other langauges/environments, without becoming disoriented is very helpful.

YMMV.

As you say, this particular pattern is less useful in C# than in C. If you need
to do a bunch of resource deallocations at the end of a method in C, for
instance, it really does help to know there's only one place the method can end.
In C# that's very rarely a factor.

I never said it was common. Just that it happens. Again, between garbage collection and IDisposable, it's much more rare in C# than it would have been before. But I don't see a need to completely abandon a potentially useful idiom just because in most cases it's not applicable.

Another example is the pattern of writing "if (0==x)" rather than "if (x==0)" in
C, in order to avoid problems due to accidentally writing a single = sign
instead of a double. Again, this just isn't an issue in C#.

It's not really an issue in C/C++ either, at least it hasn't been for a very long time. I don't recall whether this was a Microsoft feature or a general C/C++ specification feature, but I've used the "assignment in if()" warning for over a decade (in conjunction with "warnings as errors", which has always been a habit), for this very reason. And yes, I agree the "constant first" syntax is less readable.

By the way, note that it's not true that "this just isn't an issue in C#". C#'s rules mitigate the situation a lot, but you can still assign a boolean in an if() statement without an error. (You do get a warning, but again...that's something that's been in at least the one C/C++ compiler I've used for a very long time).

[...]
I agree that it's still important to be aware of the options available, but
sometimes they become so rarely useful that it's no longer worth keeping them as
what you might consider your general coding style. (Generic "you"
here, of course.)

Well, I guess that depends on your definition of "general coding style". As I said, I don't have a consistent "I always do it one way or the other" attitude for this specific question. It's more about anticipating possible future uses, and weighing the relative aesthetics between the approaches.

Consistency can be a good thing, but it shouldn't be clinged to when there are more dominant issues. For different people, what defines "more dominant issues" may vary (and in matters such as these, they practically always will).

Pete
.

Relevant Pages

  • Re: briefly
    ... internalized language in the first person plural feature can't make the ... concept by habits of thought. ... Jargons and notations get invented ... In short, I don't think Sapir-Whorf, even fairly strong versions of it, ...
    (rec.arts.sf.written)
  • Re: Intro to Programming w/ Machine Language
    ... > of bad habits, that you have to break to be able to effectively program ... > in a suitably high level language. ... and to approach programming as a sequence of tasks that a ... > iteratvie languages, functional languages tend to become more difficult ...
    (comp.programming)
  • Re: Intro to Programming w/ Machine Language
    ... > of bad habits, that you have to break to be able to effectively program ... > in a suitably high level language. ... and to approach programming as a sequence of tasks that a ... > iteratvie languages, functional languages tend to become more difficult ...
    (alt.lang.asm)
  • Re: JustBASIC as roguelike programming language
    ... the way the language is designed, it encourages very bad programming ... habits, that later bite you in the back in larger projects. ... that the language itself doesn't encourage or even suggest -- you have to ... modifying for loop index inside the loop ...
    (rec.games.roguelike.development)
  • Re: Curly bracket question
    ... up until they are slightly painful). ... It's feedback will help ... you learn good habits quickly. ... Don't let a warning pass ...
    (comp.arch.embedded)