Wasted space
-
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
-
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
This looks quiet obvious to C, C++, C#, JavaScript and Java programmers, but maybe not for others. Are you refering to some specific implementation?
Best regards, Jaime.
-
This looks quiet obvious to C, C++, C#, JavaScript and Java programmers, but maybe not for others. Are you refering to some specific implementation?
Best regards, Jaime.
It was in Java, but I guess I was thinking of any C derived language.
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
-
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
No, no, you want a
Dictionary<bool,string>, then useappendField( booldic [ value ] , lastField);:-D -
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
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 Archive -
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 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. -
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.Ah, see? My Dictionary technique works with that situation too! :-D
-
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.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
-
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
Jim (SS) wrote:
A function is reasonable if you just put the one line in it.
Yes, that would make maintenance easier, and I would hope that the compiler would inline it.
Jim (SS) wrote:
25 row by 80 column displays
Your display had 25 rows? Lucky dog. I was stuck with 24, but I could select 132 columns. :cool:
-
Jim (SS) wrote:
A function is reasonable if you just put the one line in it.
Yes, that would make maintenance easier, and I would hope that the compiler would inline it.
Jim (SS) wrote:
25 row by 80 column displays
Your display had 25 rows? Lucky dog. I was stuck with 24, but I could select 132 columns. :cool:
PIEBALDconsult wrote:
I was stuck with 24, but I could select 132 columns
Youngster. Of course I forgot about the 1 line by 80 display I had before that (punchcard). :cool::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
-
PIEBALDconsult wrote:
I was stuck with 24, but I could select 132 columns
Youngster. Of course I forgot about the 1 line by 80 display I had before that (punchcard). :cool::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
Luxury. All we had was a single red light and a toggle switch.
-
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
Jim (SS) wrote:
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
The worst thing I remember from those days (and please forgive me, I was young) was working with a system with twin 1Mb 8" floppies - no HDD in them days. We had to use functions to save on disk space; if the source code grew too big, there wasn't space to assemble / compile it unless... ...we removed all the comments to make enough space. Gulp. :omg: I even wrote a utility to automate the process of deleting the comments.
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
-
Luxury. All we had was a single red light and a toggle switch.
-
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
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.
-
Jim (SS) wrote:
A function is reasonable if you just put the one line in it.
Yes, that would make maintenance easier, and I would hope that the compiler would inline it.
Jim (SS) wrote:
25 row by 80 column displays
Your display had 25 rows? Lucky dog. I was stuck with 24, but I could select 132 columns. :cool:
PIEBALDconsult wrote:
I would hope that the compiler would inline it
The compiler would not but the JVM might if it was declared final. Final variables might be inlined by the compiler but method calls are not. The reason is that the compiler cannot know what version of the class will be loaded at runtime, so a method which was declared final at compile time may not in fact be final at runtime. The JVM does know what version of the class is being loaded, so it can make this decision. http://www.javaperformancetuning.com/tips/final.shtml[^]
-
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.
I can't argue with those comments. I was just explaining why some coding practices bother me so much. Most developers today don't even understand the concept of hard real time, where you had to account for each processor cycle. Unless you are doing embedded or 3D graphics, processing time is not a major issue. I set my IDE to as wide and tall as I can get it, but still if I'm constantly scrolling to get the meaning of a piece of code, I prefer more compact code. I guess code is like a gun. The best gun for you is the one you feel most comfortable with.
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
-
This looks quiet obvious to C, C++, C#, JavaScript and Java programmers, but maybe not for others. Are you refering to some specific implementation?
Best regards, Jaime.
Your reply appears to imply that C# code should look obvious to people who don't know C#, or even C(++), Java, JavaScript, or quite a few others that have the ternary operator. Not to mention the fact that a semi-intelligent person who does not recognize this construct in C# at least should know, if maintaining the code, that the code *is* C# and be able to find out what it is. I am not sure what kind of programmers you think C# code should be written for, but personally I think it would be a mistake to attempt making C# read like VB6 for the sake of accomodating maintenance by someone who in essence is a non-programmer. I'd point out that the "overhead of a function (sic!) call" is academic - at best. The compiler may well decide to inline the code. And even if it did not, there are many cases where the microseconds (if that much) spent on pushing and popping the stack would simply make no difference whatsoever to the value of the program. To me, it is still a horror though - but because it demonstrates a lack of knowledge about the language on the part of the author more than anything else.
-
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
