The Weird and The Wonderful

Palladino wrote: Dammit! Yeah, I had the same reaction the first time I wanted to use it, some time about two years ago. I dislike large function bodies, but realistically there are a number of situation-specific algorithms that depend on a long sequence of unrepeated operations. To reduce the size, one is left with the option of breaking them into smaller chunks as subroutines, then calling each subroutine in sequence. I've seen differences in how well that approach works when maintenance is being performed by novices to the software. I've seen genuinely intense frustration expressed by some developers when they have to nest down through two or more levels of subroutine that were simply put in to eliminate very lengthy code sequences, where the developer in question felt it would have been much easier to follow the sequence in its original lengthy form. Allowing collapsible regions within a subroutine brings the best of both techniques to bear on the problem.

"Can you think of why a programmer would ever use a string to act as a bitmap field?" How about, they represent default boolean configuration settings. You can change them after the fact by patching the EX with a different string - once you find the string, of course.

I had something similar in production to fix. File had fixed length lines, every column meant something and couldn't change. But it did, suddenly some lines were one char too long, so some columns were invalid. A 2 char field was supposed to be 01, 02, or 03. An int was being used to calculate, and got incremented up to 98, 99, 100, .... More than 2 characters. The program was using C char* with strcpy and strcat, so this field being too long shifted the position of all following fields, bad data! I corrected the field to only be 1, 2 or 3 (zero prepended to make 2 chars), and added checks for the line length before outputting to a the required file. And starting using C++ class std::string instead of char* in my newer code to help my sanity.

If this sort of thing was implemented as a function, and I mean a VERY well-documented function, it would be ingenuous (especially if it was inline, where this is permitted). Otherwise, cute constructs like this are a pain in the tailbone unless you only hire coders who instantly recognize every trick in the book. Good luck with that :laugh:

You are welcome friend :) Happy coding.

GibbleCH wrote: A table with 118 columns? That's the biggest horror :omg: Might be a Fresher's work!!! Regards - Kunal Chowdhury | Software Developer | Blog | Twitter | Silverlight Tutorial | Indian Forum

I didn't think I would get voted a 2 on my post. Maybe they didn't notice the wink? Or perhaps they like the T, U, V naming convention? :omg: Just because the code works, it doesn't mean that it is good code.

I feel really sorry for you. Bosses usually really don't care about the details, maintainability, etc. All they want is what the client wants. And I often see they miss many opportunities because they are reluctant to improve things that are already working. With this kind of mentality, that companies like Microsoft gets owned by companies like Google. Improve always, think before the client.

So, it's depends on the whole code implementation... Without seeing the original code, it's not feasible to reply... :laugh: Don't forget to Click on [Vote] and [Good Answer] on the posts that helped you. Regards - Kunal Chowdhury | Software Developer | Chennai | India | My Blog | My Tweets | Silverlight Tutorial

It's just a little fix to get a value and not a Nan (french-glish comments! :laugh: ). Why do simple ?

Yes, but even if there are 9 variables, you don't need 9 different queries to populate them. I think that's the point of the OP. Instead of: SELECT X INTO vX FROM CUSTOMERS WHERE IDTYPE =linea; SELECT Y INTO vY FROM CUSTOMERS WHERE IDTYPE =linea; SELECT Z INTO vZ FROM CUSTOMERS WHERE IDTYPE =linea; you can do: SELECT X, Y, Z INTO vX, vY, vZ FROM CUSTOMERS WHERE IDTYPE =linea; The selection criteria in this case are identical for all 9 variables, so you can fetch them all in one hit.

Which is why TDD is so good. If you get interrupted, run your tests and you know where you are in your coding.

It is portable, I'll give it that. :laugh: [Forum Guidelines]

Nothing's wrong with strings that can contain embedded NULLs. The fact that NULL terminated strings are so popular is mainly historic. There are times when it's handy or even necessary for a string to contain embedded NULLs, for example the Win32 SHFileOperation[^] function uses strings that have embedded NULLs. Steve

Done - Conversion to Roman dates using a database[^] Thank you for the idea! :laugh: Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.

You guys are very punny. :laugh: Just because the code works, it doesn't mean that it is good code.

At least is doesn't do anything harmful ;) Just because the code works, it doesn't mean that it is good code.

Sadly true. At least someone corrected the error in a later post. Just because the code works, it doesn't mean that it is good code.

Great idea! I will have to suggest that my company implement that new standard for error messages :laugh: Just because the code works, it doesn't mean that it is good code.

While that code snippet may indeed produce the desired effect it is one of the most convoluted ways I have seen of doing a simple task. See my sig. You should tell that guy about the International Obfuscated C Code Contest (IOCCC[^]) Just because the code works, it doesn't mean that it is good code. modified on Wednesday, August 25, 2010 2:40 PM