|
stumbled over this code while maintaining some script for an installer  :
if ( SomeCondition ) then
...
else
if ( SomeCondition ) then
...
else
if ( SomeCondition ) then
...
else
if ( SomeCondition ) then
...
else
if ( SomeCondition ) then
...
else
if ( SomeCondition ) then
...
else
if ( SomeCondition ) then
...
else
if ( SomeCondition ) then
...
else
if ( SomeCondition ) then
...
else
if ( SomeCondition ) then
...
endif;
endif;
endif;
endif;
endif;
endif;
endif;
endif;
endif;
endif;
i guess it didn't occur to the fellow who wrote it to use elseif or switch/case 
|
|
|
|
|
does the script language support switch/case ?
|
|
|
|
|
yep...in fact I've already replaced it with switch/case ...
|
|
|
|
|
Chris Losinger wrote: does the script language support switch/case ?
 Good one!!
Smile: A curve that can set a lot of things straight!
(\ /)
(O.o)
(><)
|
|
|
|
|
IIRC there was an early version of InstallShield's scripting language which didn't have else if, so you were lumbered with this kind of thing. No switches either.
But in your case you say the language does support else if, so no excuse. But could this be an old InstallShield script that hasn't been updated as the language features have moved on?
Kevin
|
|
|
|
|
well it was written from scratch on a script version that did support elseif/switch-case, but i guess if the guy/gal was used to working on an old version that didn't support it, could be they thought the new one didn't either...
prolonged InstallShield usage does also have the capability to pretty much kill the any enthusiasm for development inside you...maybe he/she was just fed up!;P
|
|
|
|
|
I don't know about you but one of the first things I do when a new version of a language comes out is look up what's new. But I suspect many don't bother with that.
Kevin
|
|
|
|
|
Last week i was put into a maintenance project. It's big accounting project. When reviewing the code i came through one funny for loop..check this
for(int i=0;i<=7*2;i++)
{
//dosomething
}
will there be any specific reason for this type of coding ?
|
|
|
|
|
It'd probably be optimised away by the compiler anyway, perhaps it made sense to the programmer because for example it may have been to loop through two weeks so by writing the code like that it'd help him remember. Just a thought, although I personally wouldn't do it.
|
|
|
|
|
Yeah, 7*2 may be a little clearer than 14, but I'd make a constant of some kind.
I used to see things like:
# define SecondsPerMinute 60
# define MinutesPerHour 60
# define HoursPerDay 24
# define MinutesPerDay (MinutesPerHour*HoursPerDay)
# define SecondsPerDay (SecondsPerMinute*MinutesPerDay)
On a side note; the guru insisted we use defines rather than consts to conserve memory.
|
|
|
|
|
Agreed but does C# (my main language) support that type of define? I didn't think so.
|
|
|
|
|
Eh, you can use consts though. Pretty much all they're really useful for in C#...
(I do hate seeing raw numbers like that in code. Even if you put the const variable definition right above the loop, you've still created an opportunity to give the value a descriptive name. You see numDays = 7*2, you think, "ah, two weeks!" rather than wondering what the numbers signify.)
----
...the wind blows over it and it is gone, and its place remembers it no more...
|
|
|
|
|
Shog9 wrote: "ah, two weeks!" rather than wondering what the numbers signify.)
Very true
|
|
|
|
|
Ed.Poore wrote: Very true
How about a few steps further? See my reply to Shog here[^].
|
|
|
|
|
Shog9 wrote: Even if you put the const variable definition right above the loop, you've still created an opportunity to give the value a descriptive name. You see numDays = 7*2, you think, "ah, two weeks!" rather than wondering what the numbers signify.
Or, in a less primitive tongue:
A week is 7 days.
A fortnight is 2 weeks.
A day is 24 hours.
A second is 1000 milliseconds.
An hour is 60 minutes.
A minute is 60 seconds.
Conversions are handled automatically, as you would expect, and the plural terms are derived from the singulars. The definitions, of course, may appear in any order.
It always surprises me how people say they want their code to be transparent but nevertheless insist on using languages that require the most obtuse and unnatural syntax (as in "numDays = 7*2").
|
|
|
|
|
You're right - i was just pointing out how even a small change could make terrible code much easier to understand.
In reality (although it'd depend a lot on what i was doing), i'd probably have a good many more constants defined. As the code stands, even if you understand that we're talking about two weeks, there's no indication of why two weeks, rather than, say, three weeks, or a week and three days. Generally, when i'm doing something like this i'll start out by building a set of constants, starting with basic things and building up to program-specific constants (grace_period = weeks(2) or some such).
Again though, it depends what i'm doing. Ideally, a logically-complete block of code works only with a single unit of measure, as this makes it easier to see mistakes when working with it (because i can assume all constants use the same units).
----
...the wind blows over it and it is gone, and its place remembers it no more...
|
|
|
|
|
Shog9 wrote: Generally, when i'm doing something like this i'll start out by building a set of constants, starting with basic things and building up to program-specific constants (grace_period = weeks(2) or some such).
How about:
The grace period is 2 weeks.
I think you're missing my point here. Or avoiding it.
|
|
|
|
|
The Grand Negus wrote: I think you're missing my point here. Or avoiding it.
I thought your point was that i didn't go far enough breaking things down in my first post. If you're talking about syntax... it really doesn't matter that much to me; you could write these sorts of things in hundreds of different languages, what matters is that you're precise and thorough.
----
...the wind blows over it and it is gone, and its place remembers it no more...
|
|
|
|
|
Shog9 wrote: what matters is that you're precise and thorough
You forgot "natural" and "convenient". There are many forms of expression that are precise and thorough but are nevertheless not desirable because they are obscure or unnatural. This definition, for example, is precise and thorough:
numDays=0x0111;
But I wouldn't want to code that way, and certainly wouldn't want to address my apparently intelligent machine like that.
|
|
|
|
|
The Grand Negus wrote: But I wouldn't want to code that way, and certainly wouldn't want to address my apparently intelligent machine like that.
Sometimes, i don't want an intelligent machine. Sometimes, i want a stupid machine that does exactly what i tell it to do. If i want to be sent a reminder every two weeks exactly, then i expect that to happen - and it's less important to me whether i'm required to specify that time period in weeks, days, or BCD milliseconds than that it happens exactly as i say it should.
That said, convenience is nice, so long as i don't sacrifice accuracy. Ever check out Google Calendar? I can send a text message, "Dinner at 6PM" to #48368, and sure 'nuff, i'll have a reminder sent back to me at ten to six. Unless i'm travelling. In which case, it would have made more sense for me to specify the time relative to GMT, even though that sacrifices convenience for precision.
----
...the wind blows over it and it is gone, and its place remembers it no more...
|
|
|
|
|
Shog9 wrote: Sometimes, i don't want an intelligent machine... i'm travelling... it would have made more sense for me to specify the time relative to GMT...
No, it would have made more sense for you to want an intelligent machine that understood time zones and took that into consideration when you were travelling.
|
|
|
|
|
The Grand Negus wrote: No, it would have made more sense for you to want an intelligent machine that understood time zones and took that into consideration when you were travelling.
The point is, i'm travelling. I'm not necessarily in the same timezone when i expect to receive the reminder as i was when i asked that it be sent. Did i mean 6PM Mountain time? 6PM Central? Even if the system is smart enough to figure out where i am and where i was, there's a pretty good chance it'll pick the wrong 6PM. Which isn't to say the system shouldn't make an effort - it should - but if i'm really concerned about accuracy, i'd want to remove all ambiguity.
----
...the wind blows over it and it is gone, and its place remembers it no more...
|
|
|
|
|
Shog9 wrote: but if i'm really concerned about accuracy, i'd want to remove all ambiguity.
Which you could, simply by saying "6:00 pm GMT" to your intelligent machine. So what's the problem?
|
|
|
|
|
The Grand Negus wrote: So what's the problem?
No problem, so long as i understand what that's actually gonna do. As i said, the syntax doesn't really matter, so long as i'm able to specify exactly what i want.
----
...the wind blows over it and it is gone, and its place remembers it no more...
|
|
|
|
|
Shog9 wrote: the syntax doesn't really matter, so long as i'm able to specify exactly what i want...
...in a convenient and natural way.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
