|
Okay, which would you rather tell your boss at the end of the day:
1: I wrote 3 lines of code.
2: I used a code generator to write 5,000 lines of code for me - saved me 2 full days of work.
I'm mean hey, it's your career but if you keep going for efficiency over productivity you'll be selling hotdogs on a street corner before long. The difference is that of actual value vs. perceived value - one will get you a raise and the other will turn you into a grumpy old man who has an office in the basement next to the dumpster.
|
|
|
|
|
1a: I wrote 3 lines of code instead of 5000, saving me 2 days of work and making the application more efficient.
If your manager truly values auto-generated code volume then getting 'moved on' for writing better code is probably no bad thing, and I'm sure he'd be able to get a job at a better place than that.
|
|
|
|
|
Yeah, my post was serious.
My entire career is based upon using code generation tools to enhance perceived value.
My last performance evaluation:
Boss: So, how many lines of code did you create this year?
Me: Four million, thanks to the power of code generators.
Boss: Wow, high productivity and automation combined. You get a 20% raise.
Instead of using obvious jokes as a launching pad for grinding axes against code generation and bad management why don't you create your own rant thread. This is the perfect place to do it.
Sheesh.
|
|
|
|
|
Apologies, didn't get that it was a joke. It is too believable
(My management is not like that, or I wouldn't be working here .)
|
|
|
|
|
Well, no problem.
I've a short fuse today.
|
|
|
|
|
That's why I've always hated wizards: You never know the kind of magic they can produce!
|
|
|
|
|
Fabio Franco wrote: That's why I've always hated wizards: You never know the kind of magic they can
produce!
They've been complaining about that ever since the first "wizards" (compilers, in this case) began generating assembly code from more readable "high-level language" code...sometimes with good reason
|
|
|
|
|
You used compilers that generated assembly code?
Driven to the ARMs by x86.
|
|
|
|
|
AspDotNetDev wrote: You used compilers that generated assembly code?
LMAO, I may be missing the joke here, but yes, I did...I remember articles about MS 5.0 C's code generation vs. Borland's (now Symantec's?) Turbo C 6.0, arguing about code density vs. efficiency across memory architectures which might one day exceed sixteen bits available for data on the average person's desktop, especially with the expanding presence of the 32-bit 80386 processor in the business workplace...yes, those days. I actually entered a program in machine code into Debug which, after I saved it as reboot.com, dutifully rebooted the system every time I ran it. Bare-metal stuff, indeed...though I never got that (expletives deleted) COM port driver to work.
But then, these intermediate languages in use now often operate in environments where sequences of bytecodes can be compiled directly into the native machine code of the executing processor, so at that point we can either request a listing (if available) or use a procesor-specific disassembler (if, ahem, our license permits) to determine whether this Just-In-Time code is actually as efficient as it can be for that processsor. Or so I assume; I'm less ambitious these days about bare-metal efficiency, I just hope it's better than running the bytecode through the interpreter and leave it at that.
|
|
|
|
|
I thought perhaps you meant that the compiler generated machine code, but maybe you actually did use a compiler that generated assembly code.
Driven to the ARMs by x86.
|
|
|
|
|
...hmmm, time to up my daily dose of gingko biloba...
|
|
|
|
|
cpkilekofp wrote: They've been complaining about that ever since the first "wizards" (compilers, in this case) began generating assembly code from more readable "high-level language" code
I surely hope our wizards today don't become the compilers of tomorrow, then I'll have to hang myself.
|
|
|
|
|
I love how one branch of Microsoft evangelists preach accessors for every single class property (which I actually like), and the other one, preaches the most inflexible total hard binding of everything to the database schema
With the big advantage of automatically generating the joins
modified 20-Oct-19 21:02pm.
|
|
|
|
|
I was exposed to a similar situation but it didn't involve an auto generated tool so much as a terrible programmer. We had a stored procedure that used 13 parameters to be used as filters for a set of data that we would return to the users. After getting a complaint that the filter was acting strange I was told to review the procedure to find the bug. When I opened the procedure I noticed that an if then else chain of about 3000 combinations of variations of the select statement had been hand written to account for every scenario that could exist. The only problem was that we figured that this was only a small fraction of the coverage of code needed to work correctly we also noticed when coping the procedure it was more the 5 megs in length. We were able to shorten the script to about 12 lines of code when we finished it.
nothing
|
|
|
|
|
I've seen some long stored procedures in my day. Perhaps 100 or 200K. But nothing like what you describe. Though, there was one grouped stored procedure that was composed of a hundred or so individual stored procedures (e.g., procedure;1, procedure;2, procedure;100, procedure;101, and so on). Still, that was due to decades of hopelessly complicated business logic and workarounds, not one very simple but bloated function, like the one you described.
Driven to the ARMs by x86.
|
|
|
|
|
icestatue wrote: We were able to shorten the script to about 12 lines of code when we finished it.
How long these lines were?
Greetings - Jacek
|
|
|
|
|
SET @value = SUBSTRING(@sText, 1, CHARINDEX(@sDelim, @sText) -1)
BEGIN
INSERT @retArray (idx, value)
VALUES (@idx, @value)
END
...but why have a BEGIN in the first place?
Driven to the ARMs by x86.
|
|
|
|
|
Probably, the guy copied part of a code that belonged to an IF statement and forgot to remove the BEGIN.. END , he must have thought 'why disturb the code if it compiles well?'
|
|
|
|
|
Our contractor just discovered a piece of code in a new project written in C# this year (2011) that doesn't use the date validator.
And... why would you use three text boxes to collect a date (one each for day/month/year) and then use Javascript to validate it?
Oh, and the home grown validation code will accept 14 as a month
function checkMonth(oMonth) {
if (parseInt(oMonth.value) != NaN) {
if (parseInt(oMonth.value) > 12) {
oMonth.value = parseInt(oMonth.value) - 12;
}
}
else {
oMonth.value = "";
}
}
and 62 as a valid day
function checkDay(oDay) {
if (parseInt(oDay.value) != NaN) {
if (parseInt(oDay.value) > 31) {
oDay.value = parseInt(oDay.value) - 31;
}
}
else {
oDay.value = "";
}
}
Obviously, this person needed a vacation
P.S.
It is just a standard LOB application that doesn't need to accept weird dates.
|
|
|
|
|
Not knowing that a date validator is available is one thing, but writing such a poor validator is really a coding horror!
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
Yeah I could easily have written the 'primary WTF' (not using the date validator ... I'd probably have used DateTime.TryParse or something), but writing client side validation and then doing it wrong are definitely worthy of this forum.
|
|
|
|
|
Our coding standards say "Use Visual Studio validator controls whenever possible to ease maintenance."
|
|
|
|
|
looks fine to me!
written on 58-15-6831
regards Torsten
I never finish anyth...
|
|
|
|
|
What if the month is 25. (25-12=13)
|
|
|
|
|
fine to me - I can handle a 13. pay check
regards Torsten
I never finish anyth...
|
|
|
|