G Atwal wrote:just setting some initial values
Junilu Lacar wrote:I'd rather discuss what name is a better representation of what "lineRead" really means with respect to previousElement and largestElement. Maybe firstElement?
Junilu Lacar wrote:I wouldn't care too much about the form. For me, what deserves more attention is the intent. Why are the variables being initialized referring to the idea of "element" but the value assigned talks about a line that was read. If the concern is really about clean code, I'd rather discuss what name is a better representation of what "lineRead" really means with respect to previousElement and largestElement. Maybe firstElement?
Liutauras Vilda wrote:
Junilu Lacar wrote:I'd rather discuss what name is a better representation of what "lineRead" really means with respect to previousElement and largestElement. Maybe firstElement?
And in general it is a bit unintuitive that lineRead is communicated as an element. Elements more conventionally referring to elements within an array for example or list. But that's purely in the context of data structures.
@OP
What is that previous/largest element? What is that? Largest apple? Largest number? Anything else?
G Atwal wrote:In this case, the information is being processed as a string, but the textfiles could contain words or numbers. It is not limited to one type of information
Liutauras Vilda wrote:
Ok. And if it is a word entered there as an element, what would mean largestElement then?
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:Actually, the real semantics of the original example are:
earlier, I wrote:When you gave those two versions, the more correct of second version in respect of first one would be:
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Who needs bytecode? The assignment operators all associate to the right, as you will see from theJunilu Lacar wrote:. . . The bytecode might give you a more definitive answer . . .
Campbell Ritchie wrote:Let's see whether there is anything in the old Sun style guide. Not obviously, no
Do not use embedded assignments in an attempt to improve run-time performance. This is the job of the compiler. Example:
should be written as
Mike Simmons wrote:
Regardless, I agree with Paul's last comment. While I do think people should know the orders of precedence, for their own benefit, I don't want to rely on that in my code.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Campbell Ritchie wrote:
Who needs bytecode? The assignment operators all associate to the rightJunilu Lacar wrote:. . . The bytecode might give you a more definitive answer . . .
Not six and two threes?Junilu Lacar wrote:. . . six or a half dozen. . . .
Tim Holloway wrote:IIRC, the bytecode interpreter is a stack machine, so it would be:
1. Load value of lineRead onto stack.
2. Duplicate top of stack
3. pop and save top of stack in largestElement
4. pop and save top of stack in previouselement
Tim Holloway wrote:
As far as code generation goes, the optimiser shouldn't care which of the 2 forms you use. They'd both result in the same bytecode.