 |
|
 |
Here's one that's created in Informix 4GL (which is a horror in itself) on how to validate a from-and-to range to make sure it has no overlaps in the DB:
FUNCTION verify_location()
DECLARE c_det_cur CURSOR FOR SELECT frerc.from_loc_id, frerc.to_loc_id FROM frerc WHERE frerc.dc_id = m_i_frerc_rec.dc_id AND frerc.whse_id = m_i_frerc_rec.whse_id # check if select worked correctly IF SQLCA.SQLCODE <> 0 THEN #... RETURN TRUE, 0 END IF
OPEN c_det_cur IF SQLCA.SQLCODE <> 0 THEN #... RETURN TRUE, 0 END IF
FETCH c_det_cur INTO m_from_loc, m_to_loc
IF m_modify = 0 AND m_i_frerc_rec.from_loc_id >= m_from_loc AND m_i_frerc_rec.from_loc_id <= m_to_loc THEN CALL sh_err_msg("S2096") LET m_from = 1 LET m_modify = 1 END IF IF m_modify = 0 AND m_i_frerc_rec.to_loc_id >= m_from_loc AND m_i_frerc_rec.to_loc_id <= m_to_loc THEN CALL sh_err_msg("S2097") LET m_from = 1 LET m_modify = 1 END IF IF m_from_loc >= m_i_frerc_rec.from_loc_id AND m_from_loc <= m_i_frerc_rec.to_loc_id THEN CALL sh_err_msg("S2097") LET m_from = 1 LET m_modify = 1 END IF IF m_modify = 0 AND m_to_loc >= m_i_frerc_rec.from_loc_id AND m_to_loc <= m_i_frerc_rec.to_loc_id THEN CALL sh_err_msg("S2096") LET m_to = 1 END IF
IF m_to = 0 AND m_from = 0 THEN WHILE SQLCA.SQLCODE = 0 FETCH c_det_cur INTO m_from_loc, m_to_loc
IF m_i_frerc_rec.from_loc_id >= m_from_loc AND m_i_frerc_rec.from_loc_id <= m_to_loc THEN CALL sh_err_msg("S2096") LET m_from = 1 EXIT WHILE END IF
IF m_i_frerc_rec.to_loc_id >= m_from_loc AND m_i_frerc_rec.to_loc_id <= m_to_loc THEN CALL sh_err_msg("S2097") LET m_from = 1 EXIT WHILE END IF
IF m_from_loc >= m_i_frerc_rec.from_loc_id AND m_from_loc <= m_i_frerc_rec.to_loc_id THEN CALL sh_err_msg("S2097") LET m_to = 1 EXIT WHILE END IF IF m_to_loc >= m_i_frerc_rec.from_loc_id AND m_to_loc <= m_i_frerc_rec.to_loc_id THEN CALL sh_err_msg("S2096") LET m_from = 1 EXIT WHILE END IF END WHILE END IF LET m_modify = 0
END FUNCTION
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
Am I missing something? Why would you do this?
protected int GetTransactionLength(string transaction) { return transaction.Length; }
is this not less code
transaction.Length
than this?
GetTransactionLength(transaction)
This may seem small, but it's just pushed me over the edge. It comes from a program that should be simple and beautiful but it full if this sort of stuff, it’s driving me nutts!
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
Depends - was the transaction.Length private? If so, then perhaps someone hasn't got up to properties in the course yet...
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
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
Nope, I have just deleted this method and used the transaction.length and it compiled fine. I could understand it if you want to manipulate the length, so I checked the history of the file in source control to see if it ever did and it's always just returned the length.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
So not only is it silly code, but silly code with public fields? Deep joy... Is the original coder still there, or have they decided to continue the course instead?
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
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
 |
outside cosmic wrote: He left.. He was Microsoft certified
ftfy
Panic, Chaos, Destruction. My work here is done.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
 |
exactly, i find it very useful to create a Getter/Setter for each member (even if it is public) just in case something changes in the future and it needs to be recovered later. Example: if the length now has to adjust, for example, +5 in the current version, simply change the code on GetTranslation(...) { return object.translation+5; } and automatically all the code that refers to this translation is conveniently adjusted.
This is no coding horror, but a wise implementation with future alterability. 
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
This is bizzare and overwrought. Perhaps he ment to do something like
protected int GetTransactionLength(string transaction) { if(transaction == null) return 0; return transaction.Length; }
CCC solved so far: 2 (including a Hard One!)
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
And if you get an zero-length string? It's uncommon, but you might want to consider returning -1 instead of zero.
|
| Sign In·View Thread·PermaLink | 5.00/5 (1 vote) |
|
|
|
 |
|
 |
This wasn't meant to be production level code, just a musing into the weird thought-processes of the original coder of this horror !
0x3c0 wrote: And if you get an zero-length string?
Heavily depends upon the context, but IMO 0 is better as, the need to differentiate between null and "" when getting the length is rare (diffent for the object itself of course).
0x3c0 wrote: It's uncommon
Nope! string foo = ""; or string foo = string.Empty; Are the best ways to declare a string if you don't already have a value for it.
The last time I got into a discussion like this, it really dragged on.... http://www.codeproject.com/Messages/3251798/NULLABLE-type.aspx[^]
CCC solved so far: 2 (including a Hard One!)
|
| Sign In·View Thread·PermaLink | 1.80/5 (2 votes) |
|
|
|
 |
|
 |
keefb wrote: Heavily depends upon the context, but IMO 0 is better as, the need to differentiate between null and "" when getting the length is rare (diffent for the object itself of course).
You're right; that requirement isn't common. But if I need it, I'd quite like to be able to get it without having to either write another method or altering the original method. It doesn't add much code, and it fits my personal coding style.
Plus, if the string is null, then retrieving Length will cause an exception. I don't like blurring cases together when one of them raises an exception.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
I just made a throw-away observation that perhaps the orginal coder meant to perform some form of null checking and got it wrong (possibly by deleting it), then the error was repeated copied and pasted.
Personally I work hard to eradicate the nulls in the first place. I tend to check parameters for null when they are passed. Becuase I want code where nulls are the driven out, I beleive in handling null reference exceptions (such as the one that would occur on string.length) as exceptions as a null value is an unexpected value (ie indicates a bug). Or at least I attempt this !
That said, if I had to, I'd wrap the string.length as per my method. This has a few of benefits: developers don't have to worry about a special -1 value; No extra code is needed to handle the -1 value (null reference exceptions will, as described above) indicate a true bug ; the result can be displayed in a UI directly as end users would assume the -1 is a bug.
CCC solved so far: 2 (including a Hard One!)
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
keefb wrote: Are the best ways to declare a string if you don't already have a value for it.
Of course that depends on the situation, but in general I disagree; I prefer null or uninitialized references.
As a particular situation: What I was working on today involves parsing some user input. For one of the parameters it's OK for the user to not specify a value (a default value will be provided later), but an empty value is not allowed. (It's possible that I'll allow an empty value in the future.) I initialize the variable to null and only assign a value if the user provided a non-empty value. Another parameter is similar, but an empty value is allowed.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
Looking for a error in a project, I saw this code.
IFormatProvider culture = new System.Globalization.CultureInfo("en-US", true); string year = itemDT["YEARBARRIER"].ToString();
string dateYear = "01" + "/" + "01" + "/" + year;
DateTime convertedDate = DateTime.Parse(dateYear, culture, System.Globalization.DateTimeStyles.AssumeLocal);
objBarrierFacade.YearBarrier = convertedDate; That can be writed with only one line.
objBarrierFacade.YearBarrier = new DateTime((int)itemDT["YEARBARRIER"], 1, 1); But I think that my solution is so easy and so obviuos to be used and other programmers need a good reason to spend more than a week in some easy use cases.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
my rule of thumb is: when some problem needs a lot of coding, there should be a shorter way to do it. Look for it! Software library functionalities like .net's are based on the survey of the necessities of millions of developers. This rule, as every one, has some exceptions.
Best regards, Jaime.
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
My favorite coding horror isn't over the top, nor does it leave the system more vulnurable than it began. But how can I honestly trust anyone who does the following:
if(!!isLocked) { } else { }
This wasn't a mistake on their part either. They used this kind of test in more than 50 places...
|
| Sign In·View Thread·PermaLink | 5.00/5 (6 votes) |
|
|
|
 |
|
|
 |
|
 |
c#5 will be shipping with this features
! => CertainlyNot() !! => DefinitelyNot() !!! => ReallyTrustMeItIsNot()
PS: still lying on the floor...
(yes|no|maybe)*
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
 |
This does remind me of the admin authentication of a custom made e-shop I saw once.
The script checked whether the user name and admin matched, but there was no check whatsoever if this user was an admin. In other words, everyone with an account on the site could get in the admin panel
Jeroen De Dauw --- Forums ; Blog ; Wiki--- 70 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65!
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
|
 |
|
 |
While I wouldn't generally use "!!" in the argument of an 'if' statement (which will inherently test whether the operand is non-zero) I see nothing wrong with using "!!" in certain contexts. For example, some compilers support bit variables and/or allow single-bit fields within a struct. If I need to set such variables based upon certain bits in a variable, I think it's cleaner to say bitVar = !!(byteVar & 0x40); than to say bitVar = ((byteVar & 0x40) != 0);. Basically, I regard "!!" as an operator which turns an integer into a Boolean. Anything wrong with that?
|
| Sign In·View Thread·PermaLink | |
|
|
|
 |
|
 |
supercat9 wrote: Anything wrong with that?
Everything! It is not an operator in the sense of being part of the language. It is a clever trick that you may understand, but is likely to confuse someone who later has the job of maintaining the code. In my experience the more simple and standard the code is the better. Whether you write bitVar = !!(byteVar & 0x40); or bitVar = ((byteVar & 0x40) != 0);, chances are the compiler will optimise it and generate the same object code.
|
| Sign In·View Thread·PermaLink | 5.00/5 (2 votes) |
|
|
|
 |