|
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.
|
|
|
|
|
Why can't you let him have his opinion without injecting your own into it.
One of the great things about being an individual is having our own view. When we find similarities, cool, when we don't, oh well.
This statement was never false.
|
|
|
|
|
Now you're dictating his wants.
That is just wrong. You can't coerce acceptance of your point of view.
This statement was never false.
|
|
|
|
|
Convenience is a matter of opinion. Seeing numDays = 7*2 is much more convenient to me than your PE examples. Its just a matter of opinion and taste. I do better with mathmatical and syntactical abstractions than I do with English. One of the reasons I chose this vocation.
This statement was never false.
|
|
|
|
|
I agree with you. Symbolic languages are much less verbose than natural languages. Natural languages also have nuances and other odd elements to it. You have none of that in symbolic languages - they're to the point and accurate (at least as accurate as you want it to be).
--
[LIVE] From Omicron Persei 8
|
|
|
|
|
The Grand Negus wrote: 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").
How is that obtuse? If you've done any basic mathematics it's very simple to understand and cannot be interpreted in the multiple ways in which English can be.
|
|
|
|
|
Ed.Poore wrote: How is that obtuse? If you've done any basic mathematics it's very simple to understand and cannot be interpreted in the multiple ways in which English can be.
It's obtuse because the expression is not natural for people outside of the programming community (which is tiny compared to the billions of others on the planet). For example, "numDays" is not a word in any dictionary I know. And "camel case" is not a normal form of capitalization. And "*" is not the usual symbol for multiplication. And "=" is not the normal way of saying "is". In other words, it's an unnatural mode of expression because it's not the way that most people would naturally express the thought.
|
|
|
|
|
Hmm, the chances of non-programmers writing programs? 
|
|
|
|
|
Ed.Poore wrote: Hmm... non-programmers writing programs?
Picture, for example, a PAL 3000 installed in a home. The homeowner says, "PAL, wake me up at 6:00 on weekdays, except for the first Thursday of every month. Use classical music." And in so doing, the homeowner has written a program. Perhaps your definition of "program", both as a noun and a verb, is too narrow?
|
|
|
|
|
You wouldn't be programming the system more like setting up some rules for a program written by programmers to activate certain tasks.
|
|
|
|
|
Ed.Poore wrote: You wouldn't be programming the system more like setting up some rules for a program written by programmers to activate certain tasks.
But how can one tell the difference, when all of the programs - top to bottom - are written in the same natural language? If someone says, "PAL, turn on pin 3 of the parallel port," is he a programmer or a user?
|
|
|
|
|
The Grand Negus wrote: But how can one tell the difference, when all of the programs - top to bottom - are written in the same natural language? If someone says, "PAL, turn on pin 3 of the parallel port," is he a programmer or a user?
Let's see here. The original post was written in a c-like variant, say C, C++, Java, or C#. We're not talking about PAL and we're not talking about a natural language interface, and the phrase "The number of days in two weeks is 7 times 2 which equals 14" cannot be used in any of the potential languages implied by the first post.
So what, exactly, is your point? It seems to me that you're taking a conceptual framework (representations of abstract concepts in succinct and accurate ways) and extending it into a realm where it is wholly impractical (e.g., the programming language itself inherently limits the clear-language expressibility of certain concepts) for the mere purpose of.. what? Picking a fight? Having the last word?
For someone programming in any c-like variant, the expression "numDays = 7 * 2;" is sufficiently meaningful to be useful, because there's a good bet the maintainer has some familiarity with the language. That's usually almost always all that matters.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
