Discussion on:

Why clean code is more important than efficient code

I recall we talked about this earlier, about Unix piping being like OO, and I posted an argument against that idea, saying that pipes were like functional programming. Maybe we're getting our terms mixed up. Are you talking about sockets, perhaps?

When I talk about the internet, I'm not equating that to Unix. I'm talking mainly about the the actual network hardware, TCP/IP, and some of the services available on the network which are arguably Unix-oriented, though they're not exclusive to it. The way I see the internet as being OO is that, separate from the server boxes, it's possible to have multiple software-based servers on one box. We can think of each software-based server as an object, because we can send messages to each of them. Though it tends to be rare, it might even be possible to send the same messages to different servers and achieve valid (though different) results. Where I think the internet is better than Smalltalk, is the internet architecture is set up to allow lots of things to go on at the same time over the same communication channel, and this is where Unix, or any other multitasking, multithreading OS help as "runtimes" for these servers/objects. What makes the Smalltalk environment smoother as a programming environment is it has some uniform rules: All messages are formatted the same way, and it has universal meta-functions that apply to all objects. This is a challenge with the internet that Alan Kay identified 14 years ago, talking about the semantic web, saying that because of the distributed non-uniformity of services on the network, there would need to be a meta-language that would allow different object systems to talk to one another, while maintaining their independence of design. I remember there being some buzz about the semantic web a few years ago, where there was a web protocol discussed (which is a frame-based solution, and not like Kay's idea), but I haven't seen anything come of it.

Re. the Ruby Way

I have heard of that book. I guess I should check it out. I checked out Ruby 5 years ago, and it reminded me of Smalltalk. When I revisited Smalltalk I found more flexibility in it than I found in Ruby, though there are some things that Ruby has that Smalltalk doesn't. One crucial thing, which I think earlier versions of Smalltalk used to have (like Smalltalk-76 and earlier), is that a method can interpret the messages it receives any way it wants to. That kind of got lost in Smalltalk-80, which is the version that most people who know Smalltalk know about. The only way this gets expressed in it is through the doesNotUnderstand handler. I talked with a guy a few months ago who did some Smalltalk programming professionally years ago, and he told me, "Yeah, that's kind of a hack, though." I have to admit I think he was right on that.

Some aspects of the system are easier if you view them as mesage based, other's object based.

If you call a method of an object, you could look it as sending a message to the object saying do this.

If you make that object an implementation detail, and then send a string to a program that owns it and it through either something as arcane as reflection, or as simple as an if statement translate it into a method call on the object, it looks more like a message, does the same thing though....

I'd rather use the most explanatory description on a case by case basis, than make my description try to explain anything and everything, which usually ends up being nothing.

Got to ask yourself this, am I trying to make the thingy fit the description, or a description that fits the thingy. Both perspectives are valid they aren't directly interchangeable though.

Do you remember that bunch of clowns who got so into the object concept and re-use they were trying to come up with a generic description of something like Order, in business terms. After a three year debate they decided that Order definitely has a unique identifier within a domain.
Any further debate revolved around sub-classing Order. No sh*t !
An affliction of nouns...
Computer langauges are much less ambiguous than spoken ones, but context is still there.

I'm not sure what you're trying to say about objects vs. messages. A message is basically the snippet of code you send to an object saying "I want you to do something." The object does something based on that message -- and, if it has a corresponding method, it executes that method. In short, a method call is a message . You seem to be trying to differentiate between the two, somehow.

For instance, let's make an object called "greeter" in Ruby:

"Hello Bob." # Returning this string is how
# your greeter response to the
# message.
Do you remember that bunch of clowns who got so into the object concept and re-use they were trying to come up with a generic description of something like Order, in business terms. After a three year debate they decided that Order definitely has a unique identifier within a domain. Any further debate revolved around sub-classing Order. No sh*t ! An affliction of nouns...

I'm afraid I don't recall such a thing, but I believe it. I imagine the language in question was probably Java.

I don't see any concrete difference beween message and object, more like point particle / wave duality in quantum mechanics.
Some aspects are best described by thinking it of it as one or the other.

It's not a message or an object, a powerful description of it will simply be consistent. i.e. it won't morph from one to the other in mid sentence, which some people do on occasion with results that run from outright confusing to hilarious.

@Tony:

I heard something about this in relation to SOA (Service-Oriented Architecture), that distributors discussed for years what fit in the category of "vegetable" or something. Each one had its little differences, and so it was extremely difficult to get agreement about what products were in which categories. The idea was to try to reach a settlement, so that an order for some food stuff could be made universally and smoothly, without idiosyncrasies based on the vendor you were dealing with. From what I heard, they were not able to settle this question to that standard.

@apotheon

Re. notions of messages

What you showed is one way of looking at message passing that's pretty traditional. Yes, a message can be a method call. What can be really cool, though, and Ruby is capable of this stuff, is an object can interpret messages sent to it.

Going back to Smalltalk, if you override the doesNotUnderstand method within your class (defined in the Object class), any message an object instance receives that does not match one of the instance's defined methods will be forwarded to doesNotUnderstand. The message will be received as an object, and you can request the keywords and the parameter data from it.

One example I cooked up was a class I called Webserver, and I used it like so:

| server document |
server := Webserver atUrl: 'http://data.bls.gov/cgi-bin/srgate'.
document := server
series_id: 'CES0000000001'
year: (2001 to: 2008) asYearInterval
format: #block
html_tables: #no
catalog: #no
delimiter: #tab
print_line_length: 400
level: 1
I used this to retrieve some employment data from the Bureau of Labor Statistics for a "homebrew" project I was working on.

I defined very few methods for Webserver, just internal management functions. This enabled me to send the message: series_id: 'CES0000000001' year: (2001 to: 2008) asYearInterval format: #block html_tables: #no catalog: #no delimiter: #tab print_line_length: 400 level: 1 to it. This is not a method call within Webserver. What happened was the message was sent to Webserver's version of doesNotUnderstand, because it did not match an existing method. What I had doesNotUnderstand do was translate the Smalltalk message to a CGI message, which mapped very nicely to: "series_id=CES0000000001&year=2001-2008&format=block&html_tables=no&catalog=no...", and send it to "http://data.bls.gov/cgi-bin/srgate" as "http://data.bls.gov/cgi-bin/srgate?series_id=CES0000000001&year=2001-2008&format=block&html_tables=no&catalog=no...". This gets back to what I was talking about earlier. A message to an object in your program is analogous to a message to some object on the internet, like a server . In fact, using this abstraction, called a proxy class, I was able to treat the web server as if it was just another object in my program.

Another example, which I picked up from a book you can get on the internet called "Squeak By Example," by Andrew Black, Stephane Ducasse, Oscar Nierstrasz, Damien Pollet, Damien Cassou, and Marcus Denker:

doesNotUnderstand: aMessage
| messageName |
messageName := aMessage selector asString.
(self class instVarNames includes: messageName)
ifTrue: [
self class compile: messageName, String cr, ' ^ ',
messageName.
^ aMessage sendTo: self ].
^ super doesNotUnderstand: aMessage
This is code I imagine most developers would want to revise, because it potentially allows all member variables within a class to be made publicly available, and I understand that's not always desirable, but it shows a similar principle. What this does is it automatically adds accessors to a class, in a "lazy evaluative" manner. Say DynamicAccessors has an instance variable called "x", but has no "getter" for it. This can be remedied by simply asking for the value of "x" like so:

| myDA someValue |
myDA = DynamicAccessors new.
someValue = myDA x.
In the third line, "x" is interpreted as a message sent to myDA. There's no method called "x" in the class, so the message gets sent to doesNotUnderstand, which is programmed to dynamically compile a new method called the same name as the message it received (only if the message matches the name of an instance variable, otherwise the object throws up it's hands and says "I don't understand this message"), which returns the value of the requested member variable, creating a "getter" for the value. It then re-sends the message to itself to have the new method execute. After this, each time the message "x" is sent to any instance of the DynamicAccessors class, it will have a method defined for that, and it will execute it (rather than going back to doesNotUnderstand).

This may look like insecure coding, and one might think I'm showing off here with cleverness, but think about this. This is the kind of thing we have wizards and IDEs do now in typical development environments. This is another way to approach it, setting "getter," and potentially "setter" policy in the object's code itself. This imbues objects with a lot more power than we're used to seeing in conventional development environments.

Those Smalltalk examples are just doing some metaprogramming in much the same vein as redefining method_missing in Ruby. I'm somewhat conversant with the technique. I haven't had much call to use it, though -- so far.

Anyway, I didn't mean to suggest that the direct correspondence to an explicitly defined method is necessary to my definition of a message. I was just offering a reasonably simple example. I wasn't saying that all messages are method calls; I was just saying that all method calls are messages (that is, calls to explicit methods comprise a subset of messages).

Metaprogramming can, as you suggest, be done safely -- mostly by avoiding eval.

@apotheon:

The metaprogramming was a bit distracting from the point I was trying to make, unfortunately. Yes, there is an equivalent in Ruby. That's the way you can have an object interpret messages dynamically in Smalltalk. What I was hoping to evoke, since I was comparing Smalltalk and Ruby earlier, was the idea of using hash arguments in Ruby. I had seen in some earlier documentation about Ruby that this was a common form: a method accepts a single fixed argument, followed by a hash table. I saw this a lot in Rails code from several years ago. In those cases methods were interpreting the messages they received.

Okay. Thanks for clarifying.

> I recall we talked about this earlier, about Unix piping being like OO, and I posted an argument against that idea, saying that pipes were like functional programming. Maybe we're getting our terms mixed up. Are you talking about sockets, perhaps? When I talk about the internet, I'm not equating that to Unix. The way I see the internet as being OO is that, separate from the server boxes, it's possible to have multiple software-based servers on one box. We can think of each software-based server as an object, because we can send messages to each of them. I checked out Ruby 5 years ago, and it reminded me of Smalltalk. One crucial thing, which I think earlier versions of Smalltalk used to have (like Smalltalk-76 and earlier), is that a method can interpret the messages it receives any way it wants to.

Please explain this idea in more detail. It sounds interesting, but I'm not quite clear on what you mean.

Okay, that's something I'll need to explore further. I knew that in FP you could achieve message passing by structuring the code in a certain way, having a function that returns a function (as an object), which is then accessed by selectors, but FP as a message passing methodology for software development sounds cool. I don't know what that means yet, but perhaps I'll find out in the near future.

Thanks.

Are you referring to the general principle behind Ruby that all functions are actually methods of Kernel? Or something else?

BTW, the Go folks (particularly Rob Pike) consider the statement "a function is a method without a receiver" to be an indication of OOP brainwashing. I tend to agree, and reverse that: a method is a function with an implied parameter.

I'm not saying that functions are methods without receivers: I'm saying that calls to functions and methods are basically just messages, in a manner of speaking. I'm abstracting the concept of the message away from the specific implementation in any given language's paradigmatic model.

most of my designs are message oriented.
Even more so I prefer the message to contain all the external information the recipient requires to meet the goal.
Real and near unmanageable complexity comes from too much indirection, what I describe as premature abstraction, and that is something modern OO IDEs really encourage, especially the ones with a lot of automatic code generation, and one of the reasons I steer well clear of that sort of thing.

Look at the ratio of scaffolding code versus 'goal' code in your design, whether hand written or produced by some wizard thingy, if most of your code is simply to support the goal, the goal will get obscured or even lost, and you'll end up spending more time maintaining the abstraction than the goal.

This is the reason why I've come to agree that languages like C++, Java, etc. are not OO. When I've really looked at them I've come to the conclusion that they institutionalize the notion of abstract data types, as that concept is understood in CS. It's the idea that data should be in a structure, and the only way that structure gets modified is by a set of routines that will take that structure as input, but it's all a gentleman's agreement, though these languages try to make it less so, but they don't entirely succeed, because they allow the developer to insert "holes" into the structure, where it can be directly manipulated, or read, and it's possible to compromise the compiler's protections of objects, which compromises the object's design integrity. To get around some of that, to enable more flexibility in design, more abstraction, they introduced the idea of interfaces as a separate concept, and its adherents admonish programmers to "program to the interface." It's a "camel" of a concept ("an animal designed by committee") filled with compromises, and it's not as powerful as the idea Kay has.

What I discovered after programming for a while in Smalltalk is that it's a lot simpler, and more powerful, because you don't have all this junk that other languages require you to put in your code, cluttering up your design, and it's not based on the idea of abstract data types. Even though I'm using Smalltalk as an example, and I'm sometimes known for Smalltalk advocacy ( ), I am really making a language design argument. There's no such thing as an "interface" construct in Smalltalk, because you don't need it. The idea is built into how objects work in it. When you're dealing with an object, you're programming to the interface, not its implementation, because it won't allow you to get to an object's implementation!

Another thing that some so-called OO languages allow (maybe this is just in C++) is for the invoker of an object to control how the object behaves via. the type of the variable that holds the object instance. This also violates one of the principles that Kay has outlined, that an object must be totally in control of its own environment.

Even so, figuring out Smalltalk code that other people have written can be pretty challenging, because the functionality is not monolithic as it is in those other languages, but is spread all over the place in little bits and pieces. Methods are often very small, maybe 10 lines of code at most. People have expressed frustration about this, which I understand. Trying to do things in a Smalltalk system can be daunting, because it's difficult to know even where to begin to look. Getting to know a Smalltalk system might be like getting to know different services on the web, to make an analogy, getting to know who can do what for you, and there are LOTS of places to look. That's the one thing the web has that Smalltalk doesn't, an easy to comprehend search engine.

when it's ended up being a business necessity to 'erm wriggle through them in a less than gentlemanly fashion.
The thing is, those holes are not some omission in the framework, they are part of it, concepts like interfacing and aggregation etc, are a flimsy patch for the hole. Sort of like bunting, or a sign saying subsidence.

If you look at the .net framework code, Borland's VCL code, and I daresay all other written in these variants, the designers will have made use of the holes, to enable functionality at a lower cost, and often in scaffolding.

An absolute classic is say accessing a private member variable of a class in static method from an instance of it.
e;g
Public MyClass
{
private int _myField;
public int MyField {get {return _myfield;}}
public static DoSomething(MyClass argInstance, int argValue)
{
argInstance._myField = argValue;
}
}

Very useful hole on occasion that, when you want to expose an internal but give it a figleaf to avoid severe blushing.

If you go down the FP route it's apples and oranges time, that particular hole can't be there. Closing it, in a language where it does exist, would mean it would be a different language altogther.

I tend to think of them as tunnels as much as I do holes.

What I was getting at was things like this:

Public MyClass
{
public int myField;
...
}

You can't do this in Smalltalk. Never. It doesn't even give you the option. What you can do is have an accessor method, something like:

myField
^myField
(The first line is the method name. "^" means "return". "myField" after the carat is the name of the instance variable) which is the simplest form of this.

I would have to threaten my fingers to make them type that in.

I've seen it in other people's code, but my team is fanatical about using FxCop, it will immediately blow up on that one, suggests you make it a constant, which is unlikely to be right, but was more polite than WTF?, Are you some sort of ****?

It would be a substantial change to the language to design that one out though wouldn't it?

Anyone who would do that, but wouldn't use a global variable, is a hypocrite.

@apotheon:

What you said would be true with a static or final member variable. The example I showed above is an instance variable, so each instance of MyClass would have a different version of "myField". Not the same as a global, but almost as dangerous. The point was this violates the principle of an object being in control of its environment.

I was saying that the kind of access it provides is evil in much the same way as a global variable. It's not the global effect that's the problem, but rather the global access, in this case. It's an instance variable, for crying out loud. Without a very, very good reason, there should not be a way to access that variable as a discrete datum -- and any such access, even when there is such a reason, should be achieved via accessor methods. Period.

> When you're dealing with an object, you're programming to the interface, not its implementation, because it won't allow you to get to an object's implementation!

I think you're being a little too imprecise here. I don't have any problem with being able to do something with an object's implementation. After all, if you couldn't do that, you couldn't implement new object designs (classes, prototypes, whatever -- depending on the particular OOP flavor you're using). Specifically, the problem is being able to access object internals; being able to alter object internals in a very intentional manner is not a problem with language design. That is, if you have an object foo , you could perhaps alter by adding the functionality offered by object bar with an extend method using the code foo.extend(bar) , but you shouldn't be able to just access instance variables of foo willy-nilly, touching the variable baz within foo by way of explicit namespace reference like foo::baz = 10 . If there's an instance variable lurking inside foo Another thing that some so-called OO languages allow (maybe this is just in C++) is for the invoker of an object to control how the object behaves via. the type of the variable that holds the object instance.

I wish I knew a little more about C# and Objective-C, so I'd have some idea whether this applies to either of them. I think not in the case of C# at least, but I've honestly never considered that specific edge case as a possibility for either language.

Not without an explicit cast, the compiler would be guessing, not a total surprise for C or unmanaged C++, though admittedly. Some hole in the multiple inheritance implementation maybe, but you'd expect a naming collision if it was that and you'd be fully qualifying it to get it to compile.
No MI in C#, and it's really serious about typing, it will even tell you to purse off if an explicit cast doesn't stand up.

Wonder what they'd call that, random duck typing?

This is what I remember about (unmanaged) C++. It's been many years since I've used C++, so I may be rusty:

class A {
public:
SomeMethod() {cout "I'm in class A\n";}
};

class B: A {
public:
SomeMethod() {cout "I'm in class B\n";}
};

void main()
{
A instanceA = B();
B instanceB = B();

instanceA.SomeMethod();
instanceB.SomeMethod();
}

This can also be written as:

SomeMethod();
}

I'm assuming that the compiler generates a default constructor and a copy constructor on its own.

The output is the same:
"I'm in class A"
"I'm in class B"

Even though I instantiated from the derived class in both cases, the object's behavior is dictated by the type of the variable that holds the instance. The only way to give back control to the object is to use the "virtual" keyword for the methods, but this is totally up to the programmer's discretion.

I am in B
Looks like another C style terseness manouvre to me, to avoid the explicit cast.
I'm not one of C or C++'s biggest fans, because of rubbish like this.
It's alright being really flexible, but having your head jammed up your arse is generally uncomforable.

That one has bitten me more than once. I think it's done that way for performance. Virtual method lookups have to occur at runtime, so they're more expensive. A case of optimizing at the high cost of maintainability, says I.

One of the main ideas in OOP, which you talked about in your comment, is information hiding. This is what I was talking about. What this enables is changing the way you store and access information within an object, without having to worry about affecting the implementations of other objects. This is what I meant by "implementation of the object." Other objects should not depend on the way (implementation) it stores information. It's not that you can't go in and change code (if you noticed, Tony was talking about interfaces, and I responded to that). You can. What it means is you can't write Class A such that it stores bits of information in an array, and makes that array public, so that Class B (as a separate class) can be implemented such that it can always use the same field name to access A's array, and depend on A always storing its information as an array (what you called a namespace reference). Sure A can store its information in an array, and it may even return an array through an accessor, but because its method of storing information is always hidden (in real OOP), the programmer working on it is free to change how that information is stored at any time without affecting how other objects use the information it lets out when it's requested. This is how the concept is commonly understood.

Another aspect of this may have to do with state, but this is iffy for me. I know Smalltalk stores state in objects a lot. That's how it functions, but I wonder if that's such a good idea. I've heard Alan Kay indicate that he doesn't like the idea, but I'm not sure about that. Pure FP has a very clean way of dealing with state changes, IMO.

Anyway, in the OO paradigm I know about so far, an object may need to go through some state changes to accomplish its tasks. There's a strong temptation by programmers to depend on those state changes in using that object. The thing is, since an object's implementation should be independent of how it's used, programmers who use that object should steer clear of depending on those state changes, and an object should not demand that its user (by this I mean a different object) depend on its state changes. If it's necessary for a user to change how it accesses information after a certain point, then a new object should be generated by the first object, which presents an interface that indicates, "You now need to do something different to continue."

It seems we agree fully, then. I just wanted to make the language used a bit more explicit.

I remember from SICP they recommended a top-down approach to design. In the initial phase they recommended you engage in "wishful thinking." In other words, you haven't written the details yet of how you're going to accomplish what you want. You're just writing, "This is what I want accomplished." This also brings to mind "goals" for me. After you've done that, they recommended looking at:

- What are the primitives?

- What are the means of combination?

- What are the means of abstraction?

I think from this they said you could determine primitives, which are the base level actions that everything else will depend on.

The thing is, it's difficult to imagine doing this within the existing software development culture, which values constructing things out of pre-existing frameworks, which have already made a lot of these decisions for you.

Getting back to what Alan Kay said about architecture (at the bottom of my comment to which you responded), the main point I meant to get across was he said it's possible to separate "meaning" from "optimization." I liked this idea, because it would contribute to two goals you talked about: clear code, and optimization for speed, because if you separate "meaning" from optimization, that means you can be clear in your meaning (your goals), while maintaining some benefits of speed that you want. I think what he was getting at, though, is that the underlying architecture--the runtime--has to support this in order for both goals to be achieved simultaneously. That's the rub for a lot of developers, because sometimes this works out, and other times it doesn't. And there's the issue that one single architecture may not be able to do this for you at all times in a project. It seems he's been dealing with this issue, from what I've seen of his recent work, because he and other people he's worked with have talked about compilers which can be altered in the midst of the application code the programmer is writing! Quite a concept!

Thank you all for providing me with quality entertainment. I'll lurk back to check for more, later.

I meant it when I said that.
I know that you know it, but turning it into a reality takes some doing, for anyone.
I know it too, but that doesn't stop me from tearing myself up over mistakes, either.
Having kids helps though, brings perspective.
If I were to mess up in a way that puts my kid in danger (which my mind tells me is an ever-present possibility, according to the flash images I get whenever I look at anything remotely dangerous), self-blame or "I'm sorry" won't be worth a damn thing.
It's like the remaining half of an army doing the seppuku in self-imposed penance for letting the other half get killed.
Catch the ball in the air, land on your feet, get it right the second time around.
Beating oneself up about a mistake amounts to luxury, it can wait.

"Premature optimization" ... that is deep.
So, in a nutshell: You wrote optimizable code.
Wouldn't be optimizable if it wasn't non-optimal, that's the surface interpretation.
Wouldn't be optimizable if it's not clear, that's the better one.

While I agree that it is a good idea to be a little easier on myself, I tend to try to err on the side of being hard on myself -- because, frankly, it seems optimal (har) to me to be just slightly harder on myself than any reasonable person. Being less hard on myself than a reasonable person makes me more prone to inexcusable error somewhere along the line.

I also feel like I have a bit of a duty to be harder on myself than on others. Better that than hypocrisy.

... for every sub-optimal piece of code I've ever written. But they haven't minted enough of them yet.

An unfalsifiable theory is no longer a theory, it's a belief system.
So, what do you think "non-optimizable" really entails?
I get the association chain "complete" > "finished" > "done for".
Of course, it begs the question "Why can't it be optimized?"

from the truth, far as I see it.
As I see it, there is no hard or soft. There is to know, or to second-guess.
You are aware of the tao, so that can help you see what I mean: There is a me that holds no mysteries, if only I could see it.
As long as I'm being hard on myself, I'm not really dealing with myself, simply cracking the whip in the dark, blindly. If I really knew myself, I wouldn't need to hit at all, not myself, and not others. And the way to know myself, I feel, starts from sympathy and identification, not from judging and evaluating.

Besides, that other me, why would he/I wish to get to know a judgmental ass/me who swings a whip at him in the dark?

Oh, no -- you referenced the Tao. That's cheating.

Obviously, I am helpless before your argument.

I do not rely on the Tao for my argument, only refer to how things can be devoid of secrecy and yet unknown.
What I mean is, being a perfectionist, beating myself up about mistakes I make, that's really just testament to not knowing what I'm doing... not in the usual sense, mind you.
The usual sense is that of incompetence... what I'm getting at is more of a disjunction of the self, one hand not knowing what the other is doing, sort of.
See, if I knew what I was doing - if I trusted myself with that knowledge - I'd be able to advise myself, negotiate better choices, lend a hand. There would be no need for the whip, because there would be no blunders, only choices - hopefully well guided ones.
But if a choice turns out not to be well guided, just change the database underlying the guidance. Learning, is what that is.

Sorry about the poetic flim flam, turns out I can't put this in writing as it is.

I wonder if your response indicates that you thought I was being sarcastic.

I pretty much got all of that from your previous comment (though I like the explication -- it's well-turned phrase). I simply yielded the floor.

This thread should be required reading for every programmer from student upward. Reading it has been one of the most instructive hours of my life. Thank you everyone who contributed.

I just wish someone had taught me a lot of this stuff instead of having to find out the hard way.

The days has gone where you had writing the code from scratch. now a days the trend is to use/ buy tool/open source components to customize/enhance further. i would say, for this writing clean code is important now a days. other factor is high attrition rate , New member should understand whatever you written so that they can remember you +vely.

The days has gone where you had writing the code from scratch. now a days the trend is to use/ buy tool/open source components to customize/enhance further. i would say, for this writing clean code is important now a days. other factor is high attrition rate , New member should understand whatever you written so that they can remember you +vely.

Some programmers might be geniuses, but few of them display any real intelligence.

Once upon a time, when I was programmer, I started my coding by WRITING THE CODE COMMENTS. This had several advantages, one of which was removing the need to keep in mind what I had to do as I coded. It also made it easier to spot errors or "missing" code. And, of course, it guaranteed that the code was commented. Anyone who thinks there's such a thing as "self-documenting" code is delusional. What is obvious when you write it can be "more opaque than a solid body" a week later.

Several years ago I spend\t several months at Microsoft reverse-documenting the Account Manager software. Apparently, it was just Too Much Trouble to properly document it whiloe it was being written.

that doesn't sound nice...

You wouldn't have said this.
The real problem in commercial programming is the resource required to do self documenting code or document code isn't there, and in general if you are honest about it, never was.
Most of us involved in the discussion, remember your halcyon days of yore all too well, though probably not as fondly. I started learning to code in 76, you seem to have stopped in 66.

Ken Lidster taught me that principle, and it often helps to work out the details of a design before coding begins. The only time it doesn't work is when your task is so research-based that you aren't going to find out how you need to do it until the attempt is made. Then you have to go back and fix the comments, and I'm sorry to say that edited comments never read as well as when they're written from scratch.