Comment On A Constant Barrage

I'm a bit disturbing that our standards have gotten so low that it requires no less than *six* "constants abuse" submissions to justify a single post. It's a good thing in some ways, I suppose; when you're asked to "look into a little bug in this application," it'll take you that much longer to regret every saying "sure, no problem!" [expand full text]
« PrevPage 1 | Page 2Next »

Re: A Constant Barrage

2005-07-15 14:21 • by dubwai
Alex Papadimoulis:


In fact, now that I think about it, maybe it useful after all ... if the rate of the Earth's spin were ever to change, Daniel's coworker would have to only change PAUSE_BY_6_SECONDS from "6" to "6.23" ...


Application.PauseSeconds := PAUSE_BY_6_SECONDS;




The earths rate of rotation changes on a regular basis so the joke's on you!


[;)]

Re: A Constant Barrage

2005-07-15 14:22 • by mizhi
:O Dude.  W.T.F.F.



These look like the work of people who never understood the purpose of
constants yet still somehow managed to remember their CS101 Prof's
admonition that "literals in code are bad, use constants to define
literals and use those in code."  Thus, instead of meaningful
constants such as SIZE_OF_HEADER or BUFFER_SIZE you get INT_512.

Re: A Constant Barrage

2005-07-15 14:22 • by LP
You know, I was just checking about:config in my firefox, and I noticed general.config.obscure_value as well



I found the explanation:

The general.config.obscure_value preference specifies
how the configuration file is obscured. Firefox expects that each byte in the
file will be rotated by the specified value. The default value is 13.
If this value is left unchanged, then the configuration file must be encoded as
ROT13. Autoconfig will fail if
the cfg file is not encoded as specified by this preference. A value of 0
indicates that the file is unencoded-- i.e. it is unobscured
plain text. It is recommended that you set this value to 0. (This will allow
you to skip the encoding step in part 3.)


Re: A Constant Barrage

2005-07-15 14:23 • by mizhi
38522 in reply to 38519
dubwai:

The earths rate of rotation changes on a regular basis so the joke's on you!


[;)]





Yep, that should be a function that varies on time of year, speed of
solar winds, the alignment of the planet, and the number of people are
walking east versus the number of people walking west.



[:)]

Re: A Constant Barrage

2005-07-15 14:26 • by loneprogrammer
Constants aren't, variables don't.

Re: A Constant Barrage

2005-07-15 14:30 • by Charles Nadolski
Hey, the good news is that at least the above code examples avoid the Magic Number Anti-pattern!

Re: A Constant Barrage

2005-07-15 14:40 • by Mirandir

One funny thing I just noticed is that Josh Buhler's coworker only seems to master "not" and "larger than" operators:


if(!(val.indexOf(" ")>0) || !(val.length>TWO)) {
instead of:
(val.indexOf(" ") == -1 || val.length < TWO)


And second half of above if-statement in reprise:
if(!(val.length>TWO))


And he probably would have used constants if there where any(It looks very much like Flash ActionScript 2.0).


/Mirandir

Re: A Constant Barrage

2005-07-15 15:07 • by johnl
38527 in reply to 38519
dubwai:
The earths rate of rotation changes on a regular basis so the joke's on you!

[;)]





I suppose calling it something like "duration of earth's rotation" would be too sensible...?

Re: A Constant Barrage

2005-07-15 15:17 • by JamesCurran
38528 in reply to 38525
Mirandir:
One funny thing I just noticed is that Josh Buhler's coworker only seems to master "not" and "larger than" operators:
er..um... It seems you haven't even gotten that far.....


if(!(val.indexOf(" ")>0) || !(val.length>TWO)) {
instead of:
(val.indexOf(" ") == -1 || val.length < TWO)



Make that....


(val.indexOf(" ") == -1 || val.length <= TWO)


(I should have fixed the first half of that as well, but we know what JB's Coworker really meant...)

Re: A Constant Barrage

2005-07-15 15:18 • by Mark Staggs
And this isn't even counting a submission a made a while back that has these defines in a C header file.



#define FIELD_WITH_LENGTH_FIFTY      50

#define FIELD_WITH_LENGTH_FORTY_SEVE     47

#define FIELD_WITH_LENGTH_FORTY          40

#define FIELD_WITH_LENGTH_THIRTY         30

#define FIELD_WITH_LENGTH_THIRTY_ONE     31

#define FIELD_WITH_LENGTH_TWENTY_FIVE    25

#define FIELD_WITH_LENGTH_TWENTY         20

#define FIELD_WITH_LENGTH_THIRTEEN       13

#define FIELD_WITH_LENGTH_TWELVE         12

#define FIELD_WITH_LENGTH_TEN            10

#define FIELD_WITH_LENGTH_NINE            9

#define FIELD_WITH_LENGTH_EIGHT           8

#define FIELD_WITH_LENGTH_SEVEN           7

#define FIELD_WITH_LENGTH_SIX             6

#define FIELD_WITH_LENGTH_FIVE            5

#define FIELD_WITH_LENGTH_FOUR            4

#define FIELD_WITH_LENGTH_THREE           3

#define FIELD_WITH_LENGTH_TWO             2

#define SINGLETON_FIELD_LENGTH            1




Re: A Constant Barrage

2005-07-15 15:19 • by JamesCurran
Next is from Kyle, who found the root cause behind the failure of long-running daemons ...


TODAY = today()

YESTERDAY = yesterday()
Am I missing something here? I can see how it's a dumb thing to do, but I don't see the connection between that and the failure of long-running daemons.

Re: A Constant Barrage

2005-07-15 15:33 • by joost
38531 in reply to 38530
If that code isn't executed every day at midnight, the values will only
be right for a certain amount of time, no? But then again, 24 hours or
possibly 12 hours is not what I would call long-running for a daemon....



And WTF if this code is executed at 23:59:59'99? TODAY, YESTERDAY,
LASTWEEK and LASTMONTH (stupid capslockitis) might all be wrong then.

Re: A Constant Barrage

2005-07-15 15:33 • by dubwai
38532 in reply to 38530
JamesCurran:
Next is from Kyle, who found the root cause behind the failure of long-running daemons ...


TODAY = today()

YESTERDAY = yesterday()

Am I missing something here? I can see how it's a dumb thing to do, but I don't see the connection between that and the failure of long-running daemons.


I can only imagine that since TODAY is a constant, TODAY says the same thing as it did when the app was started as it does two weeks later.  So maybe they are comparing TODAY with TOMMORROW and determining whether to exit.

Re: A Constant Barrage

2005-07-15 15:44 • by joost
38533 in reply to 38532
It might also to unwanted effects when the year changes, but I don't
know in what format today() returns its information, i.e. if the year
is included.

Re: A Constant Barrage

2005-07-15 15:44 • by curtisk

if (totalGlue > EIGHT) totalGlue = EIGHT;

// burried in a header file ...
#define EIGHT 16


LOL that made my day, I have nothing to say but WTF!

Re: A Constant Barrage

2005-07-15 16:10 • by diaphanein
38536 in reply to 38527
johnl:
dubwai:
The earths rate of rotation changes on a regular basis so the joke's on you!

[;)]




I suppose calling it something like "duration of earth's rotation" would be too sensible...?


Rate makes much more sense.  Duration implies that it starts and ends....  Would be awfully strange if the earth just upped and stopped rotating after 24 hours.  [:D]

Re: A Constant Barrage

2005-07-15 16:19 • by mizhi
38537 in reply to 38536
Anonymous:

Rate makes much more sense.  Duration implies that it starts
and ends....  Would be awfully strange if the earth just upped and
stopped rotating after 24 hours.  [:D]





Time would stop!  [:D]



Haven't you ever seen Superman?

Re: A Constant Barrage

2005-07-15 16:35 • by travisowens
38539 in reply to 38537

mizhi:
Anonymous:
Rate makes much more sense.  Duration implies that it starts and ends....  Would be awfully strange if the earth just upped and stopped rotating after 24 hours.  [:D]


Haven't you ever seen Superman?


Unfortuetly his code never references an IGyroscope so he cannot detect if the earth's rotation rate was changing.


Also, anybody who previously said the Earth's retation is static was incorrect ( http://www.iers.org/iers/earth/rotation/ ), it does change slightly according to the distance of planets & moons in our immediate area.  Of course going with an average rotation is pretty reliable, I mean, it's not like his code is going to automate landing a probe from earth and it MUST land within a 6 inch square on Mars and he has no visual cues to go by.  Wait I take that back, he might have been a coder on previous Mars lander projects.


 

Re: A Constant Barrage

2005-07-15 16:50 • by vlewis
I am reminded of an early FORTRAN system I worked on that would allow
you change the values of constants by passing a constant to a function
which changed to value of the parameter.  So you give the constant
value 3 a value of 5 so that wherever else 3 was used it use 5 so the
expression 3 + 2 would calculate to 7.



Then that fancy virtual memory came around and people started putting
the values of number in protected pages and it took all the fun out of
it.

Re: A Constant Barrage

2005-07-15 16:54 • by ammoQ
Alex Papadimoulis:
private const int INT_ZERO = 0;
private const int INT_ONE = 1;
private const int INT_TWO = 2;
private const int INT_THREE = 3;
'...
private const int INT_TWENTY_SEVEN = 27;
private const int INT_TWENTY_SEVEN = 28;




On the ZX81 home computer, using the built-in BASIC, it was a common coding practice to do something similar; e.g.


10 LET I=1

20 LET O=0


because numeric literals required 5 extra bytes of memory for each
occurence (for speed reasons, the system stored the float value along
with the readable representation) and memory was very limited, 1KB in
the basic model.
So using this "constants" saved 5 bytes each time; the declaration of
both costs est. 24 bytes, so it pays off soon.





Next is from Kyle, who found the root cause behind the failure of long-running daemons ...



TODAY = today()
YESTERDAY = yesterday()
WEEKAGO = weekago()
LASTMONTH = lastmonth()


Hard to say if this is a WTF without knowing the background; sometimes
similar code is the right way to avoid a date switch-over during
processing which would cause bad effects. Of course, your program
should run into these lines at least once per day ;-)

Re: A Constant Barrage

2005-07-15 17:20 • by AC
38545 in reply to 38523

loneprogrammer:
Constants aren't, variables don't.


So true, thanks for the laugh

Re: A Constant Barrage

2005-07-15 17:39 • by Anonymous
38546 in reply to 38545
I ended up doing this recently.  I think I was feeling allergic to new that day.



private static final Integer INT_1 = new Integer(1);

private static final Integer INT_2 = new Integer(2);

public static final Integer MAGIC_COLUMN_A = INT_1;

public static final Integer MAGIC_COLUMN_B = INT_2;

public static final Integer MAGIC_THINGY_X = INT_2;

public static final Integer MAGIC_THINGY_Y = INT_1;

public static final Integer MAGIC_THIUGY_Z = INT_1;

etc.



Re: A Constant Barrage

2005-07-15 19:00 • by rogthefrog

Thank god for design patterns, though.


public class MyAwesomeProgram
{
  public static void main(String[] args)
  {
    MagicNumberFactory mnf = MagicNumberFactory.getInstance();
    int myMagicNumber = mnf.getMagicNumber(MagicNumberFactory.BIG);
    System.out.println("check out my magic number: " + myMagicNumber);
  }
}
class MagicNumberFactory
{
  private static int count = 0;
  public static final int BIG = 1;
  public static final int COOL = 2;
  public static final int SUPERMAGIC = 3;
  public static MagicNumberFactory getInstance()
  {
    return new MagicNumberFactory();
  }
  public int getMagicNumber(int type)
  {
    ++count;
    int theMagicNumber = 0;
    switch(type)
    {
      case BIG:
        theMagicNumber = BIG * 14 * count;
        break;
      case COOL:
        theMagicNumber = COOL * 85 * count;
        break;
      case SUPERMAGIC:
        theMagicNumber = SUPERMAGIC * 132 * count;
        break;
      default:
        theMagicNumber = count;
        break;
    }
    return theMagicNumber;
  }
}

Re: A Constant Barrage

2005-07-15 19:14 • by mizhi
38549 in reply to 38548
ROFLMAO @ rog.  If this place allowed karma awards, that'd get one.

Re: A Constant Barrage

2005-07-15 21:41 • by Davey
38552 in reply to 38548
Wa?? @ Rog



Anyways, I've been wondering why people make getIntance() methods. In what situations is this a good idea?

Re: A Constant Barrage

2005-07-16 00:18 • by vhawk
Looking at:



// Name
var val:String = name_txt.text;
if (!(val.indexOf(" ")>0) || !(val.length>TWO)) {
myMessage += "Please fill in your full Name\n";
validate = false;
}

// Address
var val:String = address1_txt.text;
if (!(val.length>TWO)) {
myMessage += "Please fill in your full Address\n";
validate = false;
}




Wonder if

'...' is more usefull as a FULL NAME or FULL ADDRESS than '.' or 'abc' or any other random 3 character  cr*p. 

Re: A Constant Barrage

2005-07-16 03:18 • by Otac0n
38555 in reply to 38554

BTW, on that last one:


"Obscure" is to be thought of as a verb, not an adjective.


 


Basicaly, this value is subtracted from the ascii value in config files, so that the files are "obscure"

Re: A Constant Barrage

2005-07-16 04:04 • by Mirandir
38556 in reply to 38528
JamesCurran:
Mirandir:
One funny thing I just noticed is that Josh Buhler's coworker only seems to master "not" and "larger than" operators:
er..um... It seems you haven't even gotten that far.....


if(!(val.indexOf(" ")>0) || !(val.length>TWO)) {
instead of:
(val.indexOf(" ") == -1 || val.length < TWO)



Make that....


(val.indexOf(" ") == -1 || val.length <= TWO)


(I should have fixed the first half of that as well, but we know what JB's Coworker really meant...)



 


Haha What the hell was I thinking... ?? [:$] Can I join the "Have-made-a-big-wtf-club" now? [:P]


 


/Mirandir

Re: A Constant Barrage

2005-07-16 04:22 • by IceFreak2000
38557 in reply to 38543
ammoQ:

On the ZX81 home computer, using the built-in BASIC, it was a common coding practice to do something similar; e.g.


10 LET I=1

20 LET O=0


because numeric literals required 5 extra bytes of memory for each
occurence (for speed reasons, the system stored the float value along
with the readable representation) and memory was very limited, 1KB in
the basic model.
So using this "constants" saved 5 bytes each time; the declaration of
both costs est. 24 bytes, so it pays off soon.





The other common trick was to use



10 LET I=PI / PI



instead of



10 LET I=1



This was because the ZX81 used a tokenised BASIC, with PI only taking
one byte. Therefore, PI / PI actually took 3 bytes to declare the
numerical value '1' as opposed to 5.



Ahhh, those were the days!

Re: A Constant Barrage

2005-07-16 07:54 • by tufty
38558 in reply to 38552
>Anyways, I've been wondering why people make
>getIntance() methods. In what situations is this a
>good idea?

getInstance (or similar) is generally a symptom of the http://c2.com/cgi/wiki?SingletonPattern

The link provided explains in excruciating detail what the pattern is about, advantages, pitfalls, how it is commonly abused and why, etc etc.

If you've not come across the concepts of singletons before, I would strongly suggest buying the 'gang of four' book and spending some considerable time browsing the c2 wiki. This is liable to reduce the WTF:LOC ratio of your work considerably[1].

Simon

[1] Unless it doesn't, of course

Re: A Constant Barrage

2005-07-16 09:00 • by spotcatbug
Alex Papadimoulis:

private const int INT_TWENTY_SEVEN = 27;

private const int INT_TWENTY_SEVEN = 28;



That's awesome.

Re: A Constant Barrage

2005-07-16 09:01 • by spotcatbug
38563 in reply to 38562
This forum software, however, is not. :/

Re: A Constant Barrage

2005-07-16 11:35 • by mizhi
38564 in reply to 38558
Hey Tufty, thanks for that website.  They have a number of interesting things there. [:)]

Re: A Constant Barrage

2005-07-16 13:14 • by divVerent
Somehow this reminds me of $TEXMF/tex/latex/base/latex.ltx[/code:

\def\@vpt{5}
\def\@vipt{6}
\def\@viipt{7}
\def\@viiipt{8}
\def\@ixpt{9}
\def\@xpt{10}
\def\@xipt{10.95}
\def\@xiipt{12}
\def\@xivpt{14.4}
\def\@xviipt{17.28}
\def\@xxpt{20.74}
\def\@xxvpt{24.88}

Seems like Roman eleven and twenty-four were half a percent smaller than ours, but to make up for this, seventeen was 1.6% larger, fourteen almost three percent and twenty as much as three point seven percent larger.

Re: A Constant Barrage

2005-07-16 14:27 • by foxyshadis
38570 in reply to 38568
divVerent:
Somehow this reminds me of
$TEXMF/tex/latex/base/latex.ltx[/code: \def\@vpt{5} \def\@vipt{6}
\def\@viipt{7} \def\@viiipt{8} \def\@ixpt{9} \def\@xpt{10}
\def\@xipt{10.95} \def\@xiipt{12} \def\@xivpt{14.4} \def\@xviipt{17.28}
\def\@xxpt{20.74} \def\@xxvpt{24.88}
Seems like Roman eleven and twenty-four were half a percent smaller
than ours, but to make up for this, seventeen was 1.6% larger, fourteen
almost three percent and twenty as much as three point seven percent
larger.




The only way this makes any sense whatsoever is if it was mixing
postscript and classical print point sizes. Although that still doesn't
explain the roman numerals.



I've been guilty of making one-time-use constants and placing then right before the function definition. >.>

Re: A Constant Barrage

2005-07-16 16:30 • by Brian
On the Power PC (and maybe on x86 too) constants may have bad data
locality and take two instructions to load.  Using gConsts.zero
rather than 0.0 may end up taking half as many instructions if a bunch
of constants are used in a function.  This is because it only has
to load the address of gConsts once then it can just use offsets to get
the other values.

Re: A Constant Barrage

2005-07-16 18:56 • by wakeskate
38576 in reply to 38558
simon:
>If you've not come across the concepts of
singletons before, I would strongly suggest buying the 'gang of four'
book and spending some considerable time browsing the c2 wiki. This is
liable to reduce the WTF:LOC ratio of your work considerably[1].




Might I suggest that if you don't know what a singleton is that you get
a book that you can actually read and follow through like "Refactoring
to Patterns".  The GoF book is really good, but it's a reference
book, not a book for learning.

Re: A Constant Barrage

2005-07-17 00:31 • by DrCode
38586 in reply to 38523
loneprogrammer:
Constants aren't, variables don't.




I believe the original was "Constants aren't.  Variables won't."

Re: A Constant Barrage

2005-07-17 07:02 • by Alexander Vollmer

Look like artifacts from an original source written in COBOL some decades ago. Often to be found in prgs for accounting and financial calcs.


Found some which made their way from COBOL through dBase to Access aso. I have an idea of beeing a very old sick man in a hospital and there is a holographic avatar serving me ... and it looks like pacman. [*-)]

Re: A Constant Barrage

2005-07-17 21:18 • by clockwise
38591 in reply to 38534
curtisk:
if (totalGlue > EIGHT) totalGlue = EIGHT;

// burried in a header file ...
#define EIGHT 16


LOL that made my day, I have nothing to say but WTF!


Don't laugh... one day it will happen to you! I have seen this in lots of code before. What happens is some idiot writes the initial system, then all of a sudden it stops working because totalGlue is allowed to be 9, and not 8. So what's the easiest change to make? Just bump it up to 16. Of course the dickhead who did this without renaming the constant should be shot. And they should have renamed it to "MAX_GLUE_AMOUNT" or something.


 

Re: A Constant Barrage

2005-07-17 23:31 • by Pax
38592 in reply to 38591
This goes back a looong way.  I beleive the original K&R suggested using the line

     #define PI 3.14159

should "the value of PI change in future".





Re: A Constant Barrage

2005-07-18 02:45 • by V.

private const int INT_ZERO = 0;
TODAY = today()


At least he's prepared if 0 would change to 100,01 in the very near feature.


Same with the fact that soon today will be known as 'the day after tomorrow'.


Surely you've thought of that designing your apps ? [^o)]

Re: A Constant Barrage

2005-07-18 04:08 • by divVerent
38594 in reply to 38570
foxyshadis:
divVerent:

\def\@vpt{5}
\def\@vipt{6}
\def\@viipt{7}
\def\@viiipt{8}
\def\@ixpt{9}
\def\@xpt{10}
\def\@xipt{10.95}
\def\@xiipt{12}
\def\@xivpt{14.4}
\def\@xviipt{17.28}
\def\@xxpt{20.74}
\def\@xxvpt{24.88}

Seems like Roman eleven and twenty-four were half a percent smaller than ours, but to make up for this, seventeen was 1.6% larger, fourteen almost three percent and twenty as much as three point seven percent larger.




The only way this makes any sense whatsoever is if it was mixing
postscript and classical print point sizes. Although that still doesn't
explain the roman numerals.



I've been guilty of making one-time-use constants and placing then right before the function definition. >.>


Well, the Roman numerals are there because TeX does not allow digits in identifiers, so they're justified. And yes, it is a point size conversion - although it's still strange to define "20 pt" as "20.74" using a macro.

Re: A Constant Barrage

2005-07-18 05:11 • by szeryf
38595 in reply to 38592
Anonymous:
This goes back a looong way.  I beleive the original K&R suggested using the line

     #define PI 3.14159

should "the value of PI change in future".






I'm pretty sure it wasn't K&R but some Xerox FORTRAN manual. It was used it many fortune files with this annotation.

Re: A Constant Barrage

2005-07-18 06:40 • by Olle
38596 in reply to 38528
JamesCurran:
Mirandir:
One funny thing I just noticed is that Josh Buhler's
coworker only seems to master "not" and "larger than" operators:
er..um... It seems you haven't even gotten that far.....


if(!(val.indexOf(" ")>0) || !(val.length>TWO)) {
instead of:
(val.indexOf(" ") == -1 || val.length < TWO)



Make that....


(val.indexOf(" ") == -1 || val.length <= TWO)


(I should have fixed the first half of that as well, but we know what JB's Coworker really meant...)



er..um... It seems you haven't even gotten that far...

!(val.indexOf(" ")>0)


allows spaces in the first position (position 0) while 


val.indexOf(" ") == -1



don't! And it is obvious that we should allow spaces in pos 0 ;-)



/Olle

Re: A Constant Barrage

2005-07-18 09:17 • by tekra
Is it just me, or did I find PAUSE_BY_6_SECONDS to be completely 
reasonable?  I.e. if I use the literal "6000", is it obvious that
is six seconds? Far too easy to accidentally type "600" or "60000" ...



tekra

Re: A Constant Barrage

2005-07-18 09:42 • by Ytram
38600 in reply to 38597
It should use a better name that doesn't include what the current
literal amount is.  Like: PAUSE_DURATION.  If there are
multiple pause durations(6 seconds, 12 seconds, 18 seconds for
example), then you should append meaningful names like SHORT, MEDIUM,
LONG.



All IMO.

Re: A Constant Barrage

2005-07-18 09:52 • by Hank Miller
38602 in reply to 38597
Anonymous:
Is it just me, or did I find PAUSE_BY_6_SECONDS to be completely 
reasonable?  I.e. if I use the literal "6000", is it obvious that
is six seconds? Far too easy to accidentally type "600" or "60000" ...



tekra




It is just you.   It should be

PAUSE_FOR_LEGAL_MINIMUM_TIME

That way when congress changes the legal minimun to be 9 you don't have
to change the name of the constant.   6 seconds is the value
today, but it might not work out for a faster machine in the future.

Re: A Constant Barrage

2005-07-18 09:59 • by Hank Miller
Alex Papadimoulis:


Of course, we could all be wrong in thinking that constants named
EIGHT are bad. Sometimes, you don't really want EIGHT to be 8, as
demonstrated by this code submitted anonymously ...


if (totalGlue > EIGHT) totalGlue = EIGHT;

// burried in a header file ...
#define EIGHT 16





He just wanted to check F and 11 on the hacker purity test.   Not to mention 8C

http://www.armory.com/tests/hacker.html



That might be enoguh to get his score out of the single digets.

Re: A Constant Barrage

2005-07-18 10:24 • by Jeroen Vandezande
38606 in reply to 38576
wakeskate:
simon:
>If you've not come across the concepts of
singletons before, I would strongly suggest buying the 'gang of four'
book and spending some considerable time browsing the c2 wiki. This is
liable to reduce the WTF:LOC ratio of your work considerably[1].




Might I suggest that if you don't know what a singleton is that you get
a book that you can actually read and follow through like "Refactoring
to Patterns".  The GoF book is really good, but it's a reference
book, not a book for learning.




"Refactoring
to Patterns" is indeed a great book!

But I can also stronly suggest "Head First: Design Patterns"

An amazing book!





regards,



Jeroen Vandezande

« PrevPage 1 | Page 2Next »

Add Comment