Jump to content
  • Advertisement
Sign in to follow this  
Ectara

A Rose by Any Other Name...

This topic is 1585 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I figure, it's my turn to try my hand at a coding horror. This one had me stumped for a couple better-spent-elsewhere hours:

menu_prompt:
	mov edx, OFFSET menu	; print menu of operations
	call WriteString
	call ReadChar
	call WriteChar
	call Crlf

	cmp al, 'p' ; If 'p' was entered...
	je print    ; ...print nodes

        ...

	mov edx, OFFSET error	; Print invalid option message
	call WriteString
	
	jmp menu_prompt

print:
	push cur
	push head
	call Print

	jmp menu_prompt
        
        ...
        
done:
	call WaitMsg	; hold display window open
	exit
main ENDP
.data
...
.code
...

Print PROC
	...
Print ENDP

I was trying to figure out how the values of the cur and head pointers weren't being stored on the stack before the call to the Print procedure; the program repeatedly generated a memory access violation when it tried to dereference the pointer, and I'd be sitting there rooting around the stack frame, and the values are nowhere to be found, like they've never been pushed on the stack before the call. Huh. Visual inspection of the code provided no answers. If you see it already, you're better read than I am on this assembler.
 
 
 
 
The answer? (MASM transforms all identifiers to uppercase by default, for case-insensitivity! Thus, my jmp statement was just jumping to the Print procedure, without pushing its parameters on the stack, instead of jumping to the print label. I have no idea why the assembler wouldn't raise an error or a warning for that, but I've learned my lesson [just started using MASM, in particular, not long ago].)

Share this post


Link to post
Share on other sites
Advertisement

Writing assembly in this day and age might be the real WTF smile.png

It's for a class I have to take; I'd really rather not have to take it, but it's required.

Share this post


Link to post
Share on other sites


It's for a class I have to take; I'd really rather not have to take it, but it's required.
At least its x86 assembly, the assembly class I had taught us 8085 assembly.

Share this post


Link to post
Share on other sites

Writing assembly in this day and age might be the real WTF smile.png

 

Hey, it's not entirely useless if you want to play with microcontrollers.

 

 

(Ok, most of them have C compilers these days...ahem...)

Share this post


Link to post
Share on other sites

Assuming that case matters and that you can safely use "Print" and "print" seems to be a bigger WTF to me.  Most of the world has long since moved on from those days, and even in places where it still does matter (such as C) seeing this kind of thing would make me wince.

 

The sooner that the rest of the world wises up and ditches case-sensitivity the better.  I long for the day when I'm writing or reading code and I no longer have to fret over whether it was really intended to use "E" or "e" (simplistic examples to illustrate a point) in the current block (particularly if they're the same type).

Share this post


Link to post
Share on other sites

Yeah apart when you are debugging someone else application, like, I don't know, something which has been written by 20 unpaid under-graduate over the course of 5 years (true story, which i guess is more common than i think), have fun with this one in a case sensitive language. Because, yes you'll find plenty of Objects oBjects ObJeCts and so on (not to mention my all time favorite: little i and big I as loop counters in the same complex nested loop) littered all over the code base making the whole thing a mess to debug.

 

 

I never run into that problem. Constant? All upper, with underscores. Composite type? Title case. Function or variable? Camel case. Dealing with others' code is behind a layer, so that the differing styles are contained.

 

So in fact you run in this problem all the time, but you're so used to work with it with a convention that you don't notice it. And hoping that everyone (current and future), everywhere, is using the exact same when you're coding with others. :p

Share this post


Link to post
Share on other sites

So in fact you run in this problem all the time, but you're so used to work with it with a convention that you don't notice it. And hoping that everyone (current and future), everywhere, is using the exact same when you're coding with others. tongue.png
On the contrary. This is making use of an available feature to one's advantage. Code using consistent capitalization rules to distinguish identifier families (such as constants, function names, variables...) is (usually) much easier to read and understand than if this is not encoded at all or using something like "hungarian" (which is an abomination, think of the LPWTF stuff in the Windows headers, for example).

Using capitalization to your advantage is in my opinion a very good compromise between "simply not knowing" and "knowing, but having to parse unintellegible letter salad".

 

Consider something like szName (which is already not that great compared to name, if you ask me, it's harder to read than necessary, impossible to pronounce, and what if you want to change the type one day?). Now you also wish to encode the fact that this is a local variable and not a function or class. So it will become something like varSzName, or szName_var. It's not improving the legibility (and intellegibility) or pronouncability of your code.

Share this post


Link to post
Share on other sites

Sorry I may explain myself poorly sometimes, english isn't my primary language and i forget that my jokes tend to fall flat.

 

Yes I agree with that, having some sort of convention (details varying from coder to coder) to name and differentiate variables / function / ... is of course a good thing no matter if the language is case sensitive or not. I am not disputing that in the slightest.

 

The point I was trying to raise, poorly I guess, is that in an environment with multiple coders over a long period of time, case sensitive languages have a tendency (in my experience, which is not that big, true) to lead to the amusing stuff I talked about in the first part of my post. It's not the fault of the language itself, but that combined with "meh" coders make the work of the debugger (me, in that case) tenfold harder as I have to check the syntax, logic (that's standard) and also triple check that each of those successive coders that are were not there anymore are really calling Save and not save or any variant of the past year used for a totally different purpose, but hey how could he know that someone else, 2 years earlier used that to save something in a part of the code he never touched.

 

The example is a bit extreme. I had to fix in a very (very) large code-base that was full of this kind of stuff during 6 months, so I may be kinda biased smile.png

Edited by SerialKicked

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!