|
I think that's what JSOP was referring to as the "bullsh|t operator".
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
Oops, I missed that. Sorry.
|
|
|
|
|
Often, in cases like that, you could very well add a comment indicating why the ojbect reference would be null (or non-null). Not always, but often.
When studying code written by others, one of the questions I frequently as myself is of the kind "OK, so I understand that you can't Do Stuff on a null object, but in which cases is the object null?? A short end-of-line comment such as 'null if child hasn't been named yet' or 'null if cleanup actions are already performed' can be worth their weight in gold.
|
|
|
|
|
On the other hand, I most definitely hate the (much too common) C construct 'while (1) {...}'
In embedded code, you frequently have infinite loops, and in some software I was handling, I declared a const bool WW3 = false, and changed the loop to 'while (!WW3) {...}'. That really upset one of the other programmers, who edited it back to 'while (1)' with some really nasty comments in the SVN log.
I tried to adopt the CHILL idea: In CHILL, 'EVER' is a reserved word, and the 'official' way of writing an infinite loop is 'DO FOR EVER [...]'. So I set up a '#define ever ;;' so that I could write (in C) 'for (ever) {...}'. But even that was too much for this other programmer; he insisted that 'while (1)' is The Professional Way of writing an infinite loop. I let him have his will.
|
|
|
|
|
I have found that "50 Specific Ways to Improve Your C#" is really good, and one of the things that the author Bill Wagner points out is that your code should be self explanatory, and not require much in comments. Good variable names helps a lot.
|
|
|
|
|
 And good function names/class names. And a alear breakdown of code into bitesized pieces. Aptly named.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
Yes. That and using good encapsulation. On one project they passed all 3-d point vectors as separate arguments. They also had 1000+ line methods.
|
|
|
|
|
The company I worked for, many years ago, had to deliver to a valued customer a pre-relase of the new and completely rewritten Fortran compiler: The old compiler could only handle 99 arguments to a function, and this customer had crossed that limit. The new compiler handled 127 arguments, but extending it to 255 arguments was a simple matter.
Another company I worked for had to update their linker program: The table of symbols defined and exported by a module could hold only 32767 elements. The customer crossed that limit. By changing the declaration of an index variable from signed to unsigned 16-bit, the linker could handle 65535 exported symbols. I believe the customer never crossed that limit - even though the software had a struct declaration of approx 8300 lines  .
|
|
|
|
|
Very hard to believe that people would even consider using 50 arguments. When I get a lot of elements I quite often will just set properties since that is easier to keep track of. When I had to pass a lot of data, I would put it in an object and pass the object. When using something like a state pattern I generally have a common area so all states can access common data. I do know that a lot of COM calls can have a lot of arguments, but that is pretty old stuff now.
|
|
|
|
|
Sure, but remember that Fortran in the 1980s didn't have anything remotely resembling an "object" concept - not even anything struct-like. The Fortran you see today has very little to do with Fortran in the second millenium. When the battles around Fortran77 was being with a lot of very far-reaching extension proposals, old guru C. A. Hoare remarked that "I don't know what programming languages will look like in year 2000, but they will be called 'Fortran'!" He ended up being right: When I first time saw a Fortran 2003 program, I honestly didn't recognize it as Fortran at all!
The common way of transferring a lot of values to a function was COMMON. A COMMON block was a named, static, unstructured/typeless block of memory. Each user of the COMMON block had his own definition of it - the order and type of variables etc. Think of it as a shared typeless pointer where each module casts the typeless block to whatever it wants (but the block was static, not heap allocated). Of course any sensible system designer would make one set of definitions, to be copied into all modules, but "include"-like compiler directives where not that common then. So if the layout was changed (say, another variable added), the change had to be duplicated in all source files.
With statically allocated COMMON blocks as the only viable alternative, and no struct-mechanisms available, it really isn't that surprising that argument lists could grow terribly long.
|
|
|
|
|
Unfortunately I do remember FORTRAN 77. It has been so long since I worked with it. I even remember working with the earlier FORTRAN. I think I remember a book called 10 statement FORTRAN that I used. I was not enamored with FORTRAN 77 mainly because it seemed like some Computer Scientists had gotten hold of it and added all this stuff for making it a general purpose programming language and not extending the math capabilities. The one thing that FORTRAN had that made it special was handling of Complex Numbers. I thought that it should have been extended to handle arrays--There were already other languages available for general programming.
|
|
|
|
|
Maybe I misunderstand what you are saying: Fortran always handled arrays, at least from Fortran 2, with 1-based indexing.
One fun detail: This 16 bit minimachine (that is, the size of a full height fridge) I was working with in the early 1980s used a 3-word (i.e. 48 bits) floating point format. The machine had an instruction called MIX3, which decremented the value in the accumulator and then multiplying by 3. MIX3 was tailor made for changing the "logicial" (1-based, 48 bits) Fortran index into a "physical" (0-based, 16-bit word) memory address. If you worry about tne "multiplication" being time consuming: It really was an addition of the accumulator, shifted one bit up, to itself, so it was faster than an ordinary add (which required an operand access).
Yes, other languages were available - Pascal dates back to 1970, and honestly: From a language design point of view, it is far, far better than the entire C group of languages. (However, it failed in system programming ascpects; a standard Pascal program resided in a single source file. If the standard had included modularization concepts, it should have beaten C to the ground...).
What kept Fortran up for so long was "the same old story": Legacy code. Fortran IV was The Standard for offering open source code (open source did NOT start with Linux!). ACM offered a huge collection of several thousand Fortran IV functions for every imaginable mathematical, engineering, or otherwise scientific, operation. I even worked on a machine whose operating system was written in Fortran (in the days when it was considered 'impossible' to write an OS in anything but assembler).
I think of old Fortran with no regrets or complaints, and enjoy all those jokes and ways of speech that came out of Fortran. Like "You can program Fortran in any programming language" (to refer to unstructured, bad code). Or "God is real, unless explictly declared integer". And then the beauty from a Xerox Fortran programming manual: "The primary purpose of the DATA statement is to give names to constants; instead of referring to pi as 3.141592653589793 at every appearance, the variable PI can be given that value with a DATA statement and used instead of the longer form of the constant. This also simplifies modifying the program, should the value of pi change".
|
|
|
|
|
Sorry I was not clear, I should have said matrix operations. Yes they had multidimensional arrays, but not matrix operations. they did add it later. The reason they did was more so that FORTRAN could be better applied to multiprocessor architectures.
|
|
|
|
|
OK, then I am with you - but for the full complement of matrix operations to be available, you have to move into our millenium  .
You had all the matrix you could think of in the open source ACM libraries, in Fortran IV syntax, from the 1970s, so you didn't have to write the functions yourself (if you were, or knew someone who was, a member of the ACM) - but the syntax is of course a lot sweeter when matrix operations are first class language elements.
Regarding parallell operations: With the Cray supercomputer, you had library functions for directly utilizing on the Cray vector registers. However, the Cray Fortran compiler was well known for vectorizing even scalar operations: If your program made, say, ten independent scalar multiplications with no ordering requirements, the compiler might collect them and set it up as one single vector multiply. In principle, this is not much more than reordering independent operations for better use of registers in a single-stream CPU, but Cray took it to extremes.
|
|
|
|
|
Yes I know they did update it years ago. My complaint is that it should have been put into FORTRAN 77. Given that it was originally the programming language for science/engineering, and I was using it in a scientific application back when FORTRAN 77 was released, would have made a lot of sense in improving its ability to handle physics and math problems instead of having to roll your own functions, or having to include the ACM libraries. It is understandable that the early version had complex numbers, and that most modern languages like C, C++, C#, etc. do not even have special functionality of complex numbers. That so much work has been put into FORTRAN compliers to better support parallel operations also makes a lot of sense since quite often scientific calculations can be excessive compute bound.
|
|
|
|
|
Reminding me of a fellow student (long, long time ago!) writing his programs using variable names like I001, I002,... F001, F002 (for floating point values). Before handing in the exercise he would to a global replacement of, say, I001 with 'NumberOfEggsPerBox' or someting like that. Writing those long names while developing the program would require too much typing, he argued.
Also it served as a limited 'copy protection'. It was too easy in those days to access the work of fellow students, to use as a basis for your own exercise solution. Martin never had his half-finished work 'stolen' - understanding it (before the last-minute variable name replacement) required as much effort as developing your own solution.
|
|
|
|
|
|
Damn you beat me to it by 15 min
Tom
|
|
|
|
|
|
Back in the Dark Ages, I worked with DEC's RT-11 operating system. It was written in PDP-11 assembler. I had the opportunity to look at the commented source code, and I remember the following line:
NOP # We don't know why it's here, but it doesn't work without it.
In a proprietary OS. From the manufacturer of the CPU.
Sometimes commentary will reveal far more than you ever wanted to know.
Freedom? That is a worship word.
-- Cloud William
The only thing a free man can be forced to do is die.
|
|
|
|
|
Like http://geek-and-poke.com/geekandpoke/2013/7/28/tdd[^]
While we are talking about assemblers: Long time ago (around the RT-11 times), I looked into the source code of the assembler, of course written in assembler. Yes, the code was commented. Only that each and every comment was like 'Smart trick here!' and 'This is messy but it works' or 'Faster than [...]'. And the module heading (that is if you consider an assembler source file a 'module' ), there was a comment referring all questions, problems and bugs to R.S, which at the time when I read it, was the CEO of a 3000 man company...
|
|
|
|
|
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
I've found that one of the hardest parts of documenting (besides overcoming the initial inertia) is to do what I call philosophical documentation.
Don't write what the code does; I can read it and tell you that. Write why you're doing that, why you chose that technique over this one, stuff like that.
|
|
|
|
|
For sticking to philosophical terms: You say that we shouldn't document the extension, but the intention.
Which fits well with the more colloquial use of the term: You document what the program was intended to do, if it was bug free. That is not necessarily what it actually does 
|
|
|
|
|
Indeed.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
