I figured that might be the case, but the point still stands that a while loop doesn't fit the flow of the program which makes it easier to make mistakes as you did when summarizing. Basically repeating code is bad, and the while loop forces repeating the input statement. Looking at the rest of the code, it's clear that get-valid-input is also being repeated several times and should go into a function, like johnsfine said.

1 members found this post helpful.

Thanks again for all your replies.

I am pleased, because you all seem to be saying what I was thinking.

@Sergei: Thanks for your acoustic example. I had a psuedo code example (above) of where I thought a do loop was necessary - I am pleased that you have provided a real life example.

It wasn't my code, and I recommended that the other guy abandon it, and start again with some clear thinking. I thought that it was important to do a design by commenting the methodolgy, That's what we did, except with a basic calculator, that had a basic design like this:

The GetFloat function has the error checking in it (like johnsfine said) - it uses scanf for simplicity. We are nearly there with having clear concise code (funny we have no do loops). The OP's code for the calculator was similar to the example code above - quite frankly a nightmare considering the simple nature of the problem, and he had 100 lines of code.

The problem with these novice coders is they tear into writing code, often without any or little idea of what they are doing. I suppose everyone has to start somewhere, but I have seen some shockers. Calling main (inside main) to restart the program was a beauty!!

You guys could have a field day with all these novices, but the problem is that one seems to be giving out the same advice over & over.

Finally, there have been no comments about my restricted Hungarian notation - do I assume the no news is good news. Wait - I shouldn't assume anything.

I hate all forms of Hungarian notation. For me they interfere with seeing the meaning of the names when I look at chunks of code. Obviously, I can look at a name and mentally cut off the type info in order to read the rest. But even when working with a lot of Hungarian notation code, I can't make myself see it that way when I read code the way I would read an English sentence (which does not require consciously reading individual words).

On this topic, I'm just not as sure as on typical programming style topics that what I see a wrong is really wrong, rather than just wrong for me.

I hate all forms of Hungarian notation. For me they interfere with seeing the meaning of the names when I look at chunks of code. Obviously, I can look at a name and mentally cut off the type info in order to read the rest. But even when working with a lot of Hungarian notation code, I can't make myself see it that way when I read code the way I would read an English sentence (which does not require consciously reading individual words).

On this topic, I'm just not as sure as on typical programming style topics that what I see as wrong is really WRONG, rather than just wrong for me.

1 members found this post helpful.

This seems to fall into that category of question where one camp says "Whoaaaa, there! Too unconventional! It causes people to create bugs!", and the other camp who expects competent readers to understand the constructs supported by the language, and to know the circumstances under which any particular construct makes sense. I stand squarely in the latter camp. I don't (usually) feel bad about using programming language features that are unconventional or obscure, and I don't light my hair on fire when I see things written in ways I don't immediately grasp.

OTOH, I do try to write code to suite my audience, if I know who that is. I would not, for example, knowingly use some obscure language element in a tutorial code sample in these forums. If I was writing code that would be expected to be efficient in some way, and know that other programmers who might read it would be skilled in using the language, I would feel quite at ease to use whatever language construct the situation called for. Sometimes, bending the code around to satisfy some other programmer's sensibilities seems counterproductive and awkward.

If I encounter code that is written in some way that seems unconventional, I start with the notion that it was written that way for some good reason. Sometimes that turns out to be true, and other times I think it does not. Many times, it forces me to think about the problem in a different way than I might naturally. Many times, it teaches me a new technique.

In other words, I don't think there is just one correct answer.

--- rod.

1 members found this post helpful.

Thanks Rod for your informative reply.

It's great to see what other peolple vastly more experienced than me do.

Thanks for the time spent in replying.

Cheers

I don't see much upside to Hungarian notation. The downside is duplicated information.
For instance, if you decide you only want single float precision, now you have to go and change the name to fScaleFactorArray everywhere you use it.

I do sometimes use "n" as a prefix to indicate a count of things (but sometimes I use "_len" as a suffix instead), eg:
but it's probably better to have the count attached to the collection:

I read "us" as short for United States, which is a bit confusing.

I'm wondering what you're getting at with the #define vs const thing here.

EDIT: all quotes refer to worzel1968's post

Hungarian notation is by large used completely wrong. It's not supposed to indicate that's already said by the type. The original point of the notation is to indicate type information that isn't indicated by *just* the type. For example, a double could actually be a length, area, or volume, and it's sometimes useful to indicate that tersely as a prefix so that it's easy to visually do some basic dimensional analysis.

I'm not sure either, since #define is a *terrible* way to express constants, because #define doesn't have any kind of scoping, and the compiler doesn't care either way.

Hi ntubski,

Maybe I am spoilt, I use KDevelop, so Find & Replace isn't a problem for me - shows how selfish I am.

I was thinking that something like DAYSINWEEK is always 7, so why not a #define - was that one of the basic uses of a #define ?

Fair enough, maybe I should change it. Ha that could start a whole new debate ....

I guess that everyone has their own style, and if coding is your work, then you will probably have to conform to your organisations coding standard. The main thing would be "To be consistent".

Thanks for your reply.

I'm wondering who you were quoting that expressed that wrong opinion regarding #define

C and C++ don't have good support for compile time constants. I think that is a flaw in the language, but that is what we are stuck with. The keyword const does not make a variable into a compile time constant. It is still a variable.

To define compile time constant integers, I always use an enum. That is a bit counter intuitive (until you are used to it). But it does everything you want a compile time constant integer to do.

For other compile time constants, I have no good answer.
#define is a very bad answer because it has no reasonable scope limits. Once you work on any really big project, you will understand how important such scope limits are.

I have used kludges, such as an inline function (defined in an .hpp file) that returns the value of a function static variable (or for simpler types, just the value). That means you need constant_name() instead of constant_name every place you use it. Also you are making extra work for the compiler in a normal build and a distracting non inlined function in a debug build. Also, the optimizer sometimes fails to sort it all out, so you end up with worse code than a simple variable would give. But I don't know a better way, especially for the common case where the constant ought to be a member of a class and defined in the class .hpp file:

You wish a class definition could include something like
so instead kludge with something like:

Hi tuxdev, thanks for your reply.

We were replying at the same time, so I didn't see this bit.

Another thing I have learnt today then. Press Save !!

I was going on what was in K&R "C Programming", I can see that this is not good in C (scoping) and in C++, because of scoping , inheritance etc

Cheers

Hi Johnsfine, we were replying at the same time so I didn't see your post either for my last post.

I like that - it's a great idea. I guess with the others I will just use const variables.

Thanks

When I was integrator of VLSI projects, we first defined naming conventions, something like this conceptually:

.

That's a (not-that-great) solution to a problem that wouldn't have existed in the first place if you used something with decent scoping.

If you use a static const variable, and the compiler can determine you never ever try to take the address of it (so there's no pointer shenanigans to to try to ninja-modify the value), the compiler is legally allowed to treat it as a true constant (and almost all compilers do, when optimizations are turned on).

Sure, Find & Replace is easy, but it's still an extra manual step that can be forgotten/screwed up. Plus, if you are using version control (and you are, of course ) then your diff is now needlessly bigger and maybe harder to merge with other people's changes.

But again, what is the upside to Hungarian notation?
But you said using const for dEarthRadiusConst is better? What's the difference?


Wouldn't a static const variable be inlinable by the compiler (I see tuxdev thinks so)? I haven't worked with floating point much, so the enum trick has always been enough for me.