flat assembler
Message board for the users of flat assembler.
![]() |
Author |
|
revolution 19 Oct 2014, 14:00
Why is it that C programmers like to use single letter variable names? i, j, f, z, y, x, c, d, g, i2, c5 etc. They communicate no information to the reader IMO and server to confuse things more.
Let's have a campaign against the use of short and uninformative variable names. Let's be more verbose and communicate more to the reader. It's not like there isn't enough disk space to store the source code or something. [/rant] |
|||
![]() |
|
Matrix 19 Oct 2014, 14:03
revolution wrote: Why is it that C programmers like to use single letter variable names? i, j, f, z, y, x, c, d, g, i2, c5 etc. They communicate no information to the reader IMO and server to confuse things more. Only did that because it was short, and locally this does not matter, those are just random temporary variables. |
|||
![]() |
|
Matrix 19 Oct 2014, 14:23
More Macronizing Abstraction
So what is written in a macro will be computed at compile time, Macro(s) can be passed to Macro(s) as input(s) so if you write a Matrix Multiplication that can be computed at compile time because you are just lazy to precalculate, it -may- be compiled as a constant. (added inverse 2x2 matrix macro) Code: I think Tomasz will like this :) |
|||
![]() |
|
HaHaAnonymous 27 Feb 2015, 01:10
[ Post removed by author. ]
Last edited by HaHaAnonymous on 28 Feb 2015, 17:51; edited 1 time in total |
|||
![]() |
|
revolution 27 Feb 2015, 01:33
The most time that you can ever save is during the initial write phase. Taking a small amount of extra time at the beginning will save more time later when you come back to the code after 12 months and wonder what hell you were doing.
Or put another way; thinking and writing a longer more descriptive variable name does take a modicum of extra time initially. But saves you more when you have to go back through all of it again a year later when you need to change something. |
|||
![]() |
|
HaHaAnonymous 27 Feb 2015, 02:00
[ Post removed by author. ]
Last edited by HaHaAnonymous on 28 Feb 2015, 17:51; edited 1 time in total |
|||
![]() |
|
neville 27 Feb 2015, 02:08
HaHaAnonymous wrote:
![]() _________________ FAMOS - the first memory operating system |
|||
![]() |
|
typedef 27 Feb 2015, 03:29
HaHaAnonymous wrote: The solution for this is documentation. Have you worked on any big projects? neville wrote: The best documentation is automatically created by well-written self-documenting source e.g. by using meaningful variable names Razz imo This Last edited by typedef on 27 Feb 2015, 04:52; edited 2 times in total |
|||
![]() |
|
revolution 27 Feb 2015, 03:35
typedef: Stop misquoting me. I already asked you to stop in another thread.
|
|||
![]() |
|
HaHaAnonymous 27 Feb 2015, 03:55
[ Post removed by author. ]
Last edited by HaHaAnonymous on 28 Feb 2015, 17:50; edited 1 time in total |
|||
![]() |
|
typedef 27 Feb 2015, 04:50
@revolution
Lol. Sorry, I forgot to take my meds. Quoted wrong person hhaha ![]() Feel free to edit my posts. |
|||
![]() |
|
revolution 27 Feb 2015, 05:06
HaHaAnonymous wrote: The solution for this is documentation. ![]() The purpose of documentation is to confuse the end users and make them feel stupid. Code: ;... proc f356 p1,p2,p3,p4 ;documentation for this function is on page 49 ;code with no comments goes here endp proc f357 p1,p2,p3,p4,p5 ;documentation for this function is on page 13 ;code with no comments goes here endp ;... |
|||
![]() |
|
redsock 27 Feb 2015, 06:46
Felt the need to chime in here, haha
I have written a fair amount of code that starts with a description of what the function does, and then proceed to write uncommented (and to the casual observer, difficult to follow) assembler (or C, C++, Java, Javascript, etc). In the context of your macro expansion/confusion in C, since indeed most of those variables are indeed "random temporaries", would the code be easier to read if they were all temp1, temp2, temp3, temp4... etc? I submit that it would not, and that a,b,c,d or x,y,z is just as easy to comprehend (if comprehension was indeed part of the original design spec). As is often the case with purely mathematic constructs, it is up to the reader to make sense of what all those mysterious x, y, z's are, and not up to the person who came up with the equation to begin with. IMO, code is not far off this mark ![]() That said, if the purpose of the function is for people to learn about what is actually happening, then x,y,z doesn't work at all, nor do register names or poorly documented code (that I am also guilty of). ![]() $0.02 thusly |
|||
![]() |
|
l_inc 27 Feb 2015, 14:30
There are cases where x,y,z and i,j,k are descriptive enough. The former are good for (surprise-surprise!) coordinates, though in some cases those need to be more specific such as xMov or xPos. And the latter are generally acknowledged as indices starting with i, which is a direct abbreviation of the word, and j,k for the cases of naming clashes.
Most important is however the documentation directly embedded into the inline comments, which is especially true for assembly code, where I normally write a description to the right of instructions for each value placed into a register. _________________ Faith is a superposition of knowledge and fallacy |
|||
![]() |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.