Wasted space
-
value ? "y" : "n"
personally I don't really like this structure. (unreadable)
V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview ArchiveUnreadable!? You may not be *used* to reading it, but don't mistake infamiliarity with anything intrinsic to the syntax. There are however some objective aspects of code: The more there is to read, the more work it is to read. The more complex the code, the more work it is. The ternary adds absolutely *no* complexity compared to a branch and is far more compact. So how can it possibly be anything but more readable? If you know of some other alternative to the ternary, other than branching, please enlighten me.
-
Unreadable!? You may not be *used* to reading it, but don't mistake infamiliarity with anything intrinsic to the syntax. There are however some objective aspects of code: The more there is to read, the more work it is to read. The more complex the code, the more work it is. The ternary adds absolutely *no* complexity compared to a branch and is far more compact. So how can it possibly be anything but more readable? If you know of some other alternative to the ternary, other than branching, please enlighten me.
don't be so upset. I just disagree with you, everybody is entitled to an opinion.
V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview Archive -
I can think of one reason for making it a method call. Imagine you have this all through your code, all over the place:
appendField(value ? "y" : "n", lastField)Now, someone comes along and says, 'We've just sold this to the Germans. "y" and "n" don't mean anything to them, it should be "J" and "N"'. You have to trawl through all the code, find every occurence of this (and any variations where Joe The Contractor has decided to do it his own way because that's how he's always done it in the past) and change them all to accept either Y/N or J/N depending on whether it's in German or English. The method itself could be more compact, but I would probably follow the DRY principal and put this sort of thing in a reusable method if it is being used a lot. I have to ask: what kind of software are you writing where the overhead of a method call is such a big performance hit? I don't know your software and it's always risky to pontificate about the "right" and "wrong" way to do things when you don't know the requirements.ANY code that is repetitive is almost always an indication that it's bad code. The main exception to this is if the code is generated. If the only thing that could change was the strings used to represent the two possible values declaring two string constants would overcome it. But the point is it's usually impossible to know what will change on a detailed level, so in software of any real complexity it's usually worth the upfront time to make code that is truly flexible. Doing so is mainly a matter of encapsulating as much as possible and making a habit of using virtual methods by default. It's a pity that human nature makes it so difficult to take a truly long term view and think ahead. Whether it's climate change or software, we too often never even consider the implications of our actions until the mess we made has become rather difficult to clean up. A lot of code has a lifetime of at least 30 years, not in the sense that it's unchanged for that long or even that it's necessarily the same technology 30 years later, but in the sense that it continues to have direct implications for that long - even though it's been amended and bugfixed and optimized and refactored and ported and supposedly "cleaned up" many times. I'm convinced of this, because I often refactor code in our only eight-year old codebase. Because absolutely everything is entangled with everything else, it's only possible to make improvements to specific parts of the system, while the complexity and chaos continues to increase at a far greater rate than we can untangle things. There may be many reasons for this, but the main one imho is quite simply that nobody ever tried to sit down and think about how to organize the code *for* long-term evolution. And I don't think we are alone in this.
-
don't be so upset. I just disagree with you, everybody is entitled to an opinion.
V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview ArchiveI'm not upset. I just found your comment ("I personally find.." with no substantiation whatsoever) stupid. I think you'll agree I'm entitled to that opinion.
-
I'm not upset. I just found your comment ("I personally find.." with no substantiation whatsoever) stupid. I think you'll agree I'm entitled to that opinion.
yes you are.
V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview Archive -
I agree with PIEBALDConsult's comment. A dictionary would work, or constants for the strings. A function is reasonable if you just put the one line in it. Now the question about performance hits. If performance wasn't an issue (and function calls do take extra time), why would we be on a quest for ever faster processors, and more cores. I guess I come from a era when performance was always an issue on any platform and for any processing. We were also limited to 25 row by 80 column displays (green, amber, black and white). That's part of the reason that the wasted space bothers me so much. That one function (with the comments) would take up most of the screen. :doh:
SS => Qualified in Submarines "We sleep soundly in our beds because rough men stand ready in the night to visit violence on those who would do us harm". Winston Churchill "Real programmers can write FORTRAN in any language". Unknown
-
May not be a horror, but what a waste of space
private void appendBooleanField( boolean value, boolean lastField )
{
if ( value )
{
appendField( "y", lastField );
}
else
{
appendField( "n", lastField );
}
}Why couldn't they replace the whole function with
appendField(value ? "y" : "n", lastField);
That reduces the line count by 10 (not counting the 7 lines of comment for the function), and removes the overhead of a function call. And, the example above is repeated over and over in the code.
SS => Qualified in Submarines "We sleep soundly in our beds because rough men stand ready in the night to visit violence on those who would do us harm". Winston Churchill "Real programmers can write FORTRAN in any language". Unknown
I think wasting space would be right at the bottom of my list of priorities. Much more important would be clarity, execution speed etc. If you really want to save space, write your source code using a smaller font.
JustAStupidGurl
-
Unreadable!? You may not be *used* to reading it, but don't mistake infamiliarity with anything intrinsic to the syntax. There are however some objective aspects of code: The more there is to read, the more work it is to read. The more complex the code, the more work it is. The ternary adds absolutely *no* complexity compared to a branch and is far more compact. So how can it possibly be anything but more readable? If you know of some other alternative to the ternary, other than branching, please enlighten me.
I don't know why you are being flamed. I like your answer.
SS => Qualified in Submarines "We sleep soundly in our beds because rough men stand ready in the night to visit violence on those who would do us harm". Winston Churchill "Real programmers can write FORTRAN in any language". Unknown
-
Jim (SS) wrote:
Now the question about performance hits. If performance wasn't an issue (and function calls do take extra time), why would we be on a quest for ever faster processors, and more cores. I guess I come from a era when performance was always an issue on any platform and for any processing.
I guess it depends on the kind of applications you write. I write maily web applications for financial companies these days. Most of the performance problems we hit are to do with transferring data over the internet at one end, or talking to the database at the other end. The overhead involved in a method call is pretty much negligible when compared to this. If one of my team spent time doing this sort of refactoring in our application to remove a method call, I would consider it time wasted. I wish I had a pound for every time I have seen someone fixing "performance issues" that didn't really exist. On the other hand, if you are writing applications that are calculation intensive, or that operate in real-time or near real-time, then this could well be a useful exercise that could make a big difference.
Jim (SS) wrote:
We were also limited to 25 row by 80 column displays (green, amber, black and white). That's part of the reason that the wasted space bothers me so much. That one function (with the comments) would take up most of the screen
This is a source of friction between me and our chief technical architect. He holds on to the old idea that a line of source code must never be more than 80 characters long. Why not? On a modern display, you get code (especially with generics) scrunched up onto the left of the screen spread over several lines not to violate the 80 character rule. And over on the right hand side you have a great big empty space that you're not allowed to type in. The reason: "Some people might have a display that only shows 80 characters". Oh please, when was the last time that you saw anyone actually using a 24x80 green screen terminal, and how likely is it that they will ever look at our code? But no, this is one of those cast-in-stone rules that must not be questioned.
David Skelly wrote:
He holds on to the old idea that a line of source code must never be more than 80 characters long. Why not?
While displays are certainly capable of displaying more than 80 characters, there are trade-offs between maximum column width, font size, and window width. If a program is mostly written using lines that happen to be 60-80 characters long, except for a few lines that are 240 characters long, then one must either tolerate having some lines which cannot be viewed in their entirety, or else widen one's windows or shrink the font, leaving most of the right 2/3 of the window blank, so the longest lines will fit. If different team members have different displays, it would seem entirely reasonable to have policies regarding preferred line width limits, recognizing that there are and should be some exceptions (e.g. if many lines of code are going to slightly exceed the desired width limit, it may be better to have them all be slightly too wide than to have every line split in two). BTW, I've sometimes wished for a programming language environment that could embed formatting marks in code so that code would wrap sensibly in the editor when necessary, regardless of screen width; such marks would have to be invisible to a compiler. Once upon a time I played around with MS-Word, but that was well over a decade ago and I never really used it.
-
David Skelly wrote:
He holds on to the old idea that a line of source code must never be more than 80 characters long. Why not?
While displays are certainly capable of displaying more than 80 characters, there are trade-offs between maximum column width, font size, and window width. If a program is mostly written using lines that happen to be 60-80 characters long, except for a few lines that are 240 characters long, then one must either tolerate having some lines which cannot be viewed in their entirety, or else widen one's windows or shrink the font, leaving most of the right 2/3 of the window blank, so the longest lines will fit. If different team members have different displays, it would seem entirely reasonable to have policies regarding preferred line width limits, recognizing that there are and should be some exceptions (e.g. if many lines of code are going to slightly exceed the desired width limit, it may be better to have them all be slightly too wide than to have every line split in two). BTW, I've sometimes wished for a programming language environment that could embed formatting marks in code so that code would wrap sensibly in the editor when necessary, regardless of screen width; such marks would have to be invisible to a compiler. Once upon a time I played around with MS-Word, but that was well over a decade ago and I never really used it.
-
Jim (SS) wrote:
Now the question about performance hits. If performance wasn't an issue (and function calls do take extra time), why would we be on a quest for ever faster processors, and more cores. I guess I come from a era when performance was always an issue on any platform and for any processing.
I guess it depends on the kind of applications you write. I write maily web applications for financial companies these days. Most of the performance problems we hit are to do with transferring data over the internet at one end, or talking to the database at the other end. The overhead involved in a method call is pretty much negligible when compared to this. If one of my team spent time doing this sort of refactoring in our application to remove a method call, I would consider it time wasted. I wish I had a pound for every time I have seen someone fixing "performance issues" that didn't really exist. On the other hand, if you are writing applications that are calculation intensive, or that operate in real-time or near real-time, then this could well be a useful exercise that could make a big difference.
Jim (SS) wrote:
We were also limited to 25 row by 80 column displays (green, amber, black and white). That's part of the reason that the wasted space bothers me so much. That one function (with the comments) would take up most of the screen
This is a source of friction between me and our chief technical architect. He holds on to the old idea that a line of source code must never be more than 80 characters long. Why not? On a modern display, you get code (especially with generics) scrunched up onto the left of the screen spread over several lines not to violate the 80 character rule. And over on the right hand side you have a great big empty space that you're not allowed to type in. The reason: "Some people might have a display that only shows 80 characters". Oh please, when was the last time that you saw anyone actually using a 24x80 green screen terminal, and how likely is it that they will ever look at our code? But no, this is one of those cast-in-stone rules that must not be questioned.
David Skelly wrote:
He holds on to the old idea that a line of source code must never be more than 80 characters long. Why not?
Oh, for the good old days, patiently inscribing COBOL statements on to 80 little boxes on an A3 size coding sheet, and just gazing at its perfect symmetry!
-
David Skelly wrote:
He holds on to the old idea that a line of source code must never be more than 80 characters long. Why not?
Oh, for the good old days, patiently inscribing COBOL statements on to 80 little boxes on an A3 size coding sheet, and just gazing at its perfect symmetry!
Richard MacCutchan wrote:
Oh, for the good old days, patiently inscribing COBOL statements on to 80 little boxes on an A3 size coding sheet
...So the punch girls could mistake 'O' and '0', '1' and 'I', and just about any other letter for just about any other letter... ...Then the operators could drop the stack of cards, but run it anyway... I had one card set returned with bits of a salad sandwich in it!
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced. This message is made of fully recyclable Zeros and Ones
-
David Skelly wrote:
He holds on to the old idea that a line of source code must never be more than 80 characters long. Why not?
Oh, for the good old days, patiently inscribing COBOL statements on to 80 little boxes on an A3 size coding sheet, and just gazing at its perfect symmetry!
I started my career writing RPG and we had the same coding sheets that you could fill out by hand. IBM also produced templates that were designed to overlay a 24x80 screen to make sure everything lined up and was in the correct column. (By which I mean actual physical templates made of cardboard.)
-
David Skelly wrote:
He holds on to the old idea that a line of source code must never be more than 80 characters long. Why not?
While displays are certainly capable of displaying more than 80 characters, there are trade-offs between maximum column width, font size, and window width. If a program is mostly written using lines that happen to be 60-80 characters long, except for a few lines that are 240 characters long, then one must either tolerate having some lines which cannot be viewed in their entirety, or else widen one's windows or shrink the font, leaving most of the right 2/3 of the window blank, so the longest lines will fit. If different team members have different displays, it would seem entirely reasonable to have policies regarding preferred line width limits, recognizing that there are and should be some exceptions (e.g. if many lines of code are going to slightly exceed the desired width limit, it may be better to have them all be slightly too wide than to have every line split in two). BTW, I've sometimes wished for a programming language environment that could embed formatting marks in code so that code would wrap sensibly in the editor when necessary, regardless of screen width; such marks would have to be invisible to a compiler. Once upon a time I played around with MS-Word, but that was well over a decade ago and I never really used it.
supercat9 wrote:
If a program is mostly written using lines that happen to be 60-80 characters long
I'm guessing that you haven't used Java generics very much.
-
Richard MacCutchan wrote:
Oh, for the good old days, patiently inscribing COBOL statements on to 80 little boxes on an A3 size coding sheet
...So the punch girls could mistake 'O' and '0', '1' and 'I', and just about any other letter for just about any other letter... ...Then the operators could drop the stack of cards, but run it anyway... I had one card set returned with bits of a salad sandwich in it!
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced. This message is made of fully recyclable Zeros and Ones
OriginalGriff wrote:
So the punch girls could mistake 'O' and '0', '1' and 'I', and just about any other letter for just about any other letter
Good excuse to ask her out for a drink ;)
OriginalGriff wrote:
Then the operators could drop the stack of cards, but run it anyway
Yeah, we had power when I was an op.
OriginalGriff wrote:
I had one card set returned with bits of a salad sandwich in it!
Probably went through the sorter first. :laugh: :laugh:
-
I think wasting space would be right at the bottom of my list of priorities. Much more important would be clarity, execution speed etc. If you really want to save space, write your source code using a smaller font.
JustAStupidGurl
-
I think wasting space would be right at the bottom of my list of priorities. Much more important would be clarity, execution speed etc. If you really want to save space, write your source code using a smaller font.
JustAStupidGurl
Nah, for real space savings you also want a propotional, kerned font, and only use thin letters and numbers! ;)
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced. This message is made of fully recyclable Zeros and Ones
-
I don't know why you are being flamed. I like your answer.
SS => Qualified in Submarines "We sleep soundly in our beds because rough men stand ready in the night to visit violence on those who would do us harm". Winston Churchill "Real programmers can write FORTRAN in any language". Unknown
-
I am familiar with the ternary. I have never liked and probably never will. I find it insufficiently readable. Also, I would like to think my opinion is not due to stupidity.
Are you familiar with the words obviate, relegate and denigrate? Many people aren't, but that doesn't mean that they shouldn't be used in common english language. By using words that have more meaning in them, we are able to shorten (use concision) our sentences while still conveying the same meaning. I think the same thing applies in writing software. By using appropriate structures and controls we are able to shorten the code while still conveying the same meaning both to the compiler and the reader. Please don't think that I am denigrating your code reading skills, I am just saying that sometimes extraneous words can be obviated.:cool:
SS => Qualified in Submarines "We sleep soundly in our beds because rough men stand ready in the night to visit violence on those who would do us harm". Winston Churchill "Real programmers can write FORTRAN in any language". Unknown
-
value ? "y" : "n"
personally I don't really like this structure. (unreadable)
V.
Stop smoking so you can: Enjoy longer the money you save. Moviereview ArchiveI suspose you also believe lambda expressions shouldn't be used either? They are even harder to read but shorten the amount of written code by huge degrees. I wrote my first one today. Granted it's quite simple but its effective. return ModifiedKeys.First(kvp => kvp.Value == id).Key; Just to help you out, ModifiedKeys is a Dictionary. This line returns the first key in my dictionary who's value matches id.
