The Lounge - CodeProject

Yes.

When I started, you could only have 8 "significant characters" in function or variable name. Nowadays that is not a problem but I still don't like long descriptive function names. I prefer short functions that you can understand with one look.

jhaga

I certainly would prefer two functions "Setup_Serial_Port" and "Activate_Serial_Port" Smile | :)

(I like short function bodies, too!).

In an OO environment, I would accept (even prefer) methods "Setup" and "Activate" on a Serial_Port object. But I would not accept "SSP" and "ASP" (or "SAASP"), even if that would save a few keystrokes when you make a call.

Many years ago (even years before Linux!) I worked with a company writing their own OS. A complete rewrite was made in a (proprietary) high level language, embraced by the old assembly programmers because "Now we don't have to write comments any more!"

It is at the same level as one introduction to COBOL-60 declaring that with this language, there is no longer a need for specially trained programmers; now anyone can write the solution in plain English language.

With a name like Setup_And_Activate_Serial_Port, there is no need for the comment to explain that this function will set up and activate a serial port. If the arguments have similarly descriptive names, you need not, in the comments, repeat what the name reveals. But I very rarely if ever see function definitions where all and everything of what the code maintainer ought to know can be expressed in the name alone (with a possible exception for 1-2 line bodies). So there is usually a need to document a lot of other aspects.

The comment associated with the function heading I prefer to keep short; it is for the user of the function, not the maintainer. And I love end-of-line comments: At the exact spot it applies to, and it won't cause the function body to spread over multiple screenfuls. (But with all EOL comments running from col 70 or 80, so they don't blur the code, you may need to widen your editor window or use the horizontal scroll bar to see them.) For some reason, most programmers disagree with me.

Generally speaking: These huge comment blocks above the function, essentially repeating information already present in (good) naming, and very little extra info, I think of as plain LOC boosters. They are no excuse whatsoever for not commenting non-obvious issues through the code (although they are often used for that purpose Smile | :)

). Two thirds of all the code comments I see have no value whatsoever, and at least two thirds of the issues that really could need an explanatory comment is left as plain, uncommented code. If I were to grade coders by their comments, very few would even reach a 'C'. Quite a few would flunk.

I used to work for a company that completely discarded the comments in the code on behalf of self-explanatory names and short functions(C++/C#). I also worked for another one where it was expected that we write a small novel on top of every function(C/Java). I like the former approach better.

Advertise here – minimum three posts per day are guaranteed.

Of course the second allows one to document things like expectations, current usage and unusual usages that come about when one ends up maintaining legacy code written by someone that left the company 10 years ago and figured keeping all that domain knowledge in their head was the sign of a professional.

trønderen wrote:
you may need to widen your editor window or use the horizontal scroll bar to see them.) For some reason, most programmers disagree with me.

That is not an option on a VT screen.
Similarly, some systems such as Oracle's PRO*C put a limit on line lengths.

Personally, I prefer not to exceed 112 characters because that's how many I can fit on a page.

PIEBALDconsult wrote:
That is not an option on a VT screen.

What year was the most recent VT terminal released? Wikipedia describes the 1993 VT520 (i.e. 30 years ago), discontinued 10 years later (20 years ago). I doubt that there were later VT screens.

According to Wikipedia, the 1987 VT320 (and its successors) could display 132 chars/line, leaving room for 62 chars of end-of-line comments starting at col 70. In the age of non-graphic, character oriented screens, it was commonplace for editors to provide a command to move the window to the right by, say, 20 or 40 characters. For the first generation of character screens, the entire screen had to be redrawn. More 'recent' models provided escape sequences for moving the contents in a line buffer (in the terminal) to the right or left, so only the new part had to be transmitted. Editors of the time fine-tuned their output to the terminal model in use, to reduce data transmitted.

Similarly, some systems such as Oracle's PRO*C put a limit on line lengths.

They can't possibly have had a limit less than 132! I worked with editors having a 256 char limit, some time in the 1980s.

I googled 'Oracle PRO*C', and was sent to the documentation for version 12.1; it seems to be released in 2014. At that time, the 'Precompiler options' documentation for MAXLITERAL states

The maximum value of MAXLITERAL is compiler dependent. For example, some C compilers cannot handle string literals longer than 512 characters, so you would specify MAXLITERAL=512.

This is a (semi-)reasonable limit, but not one preventing you from using end-of-line comments! The limit may of course have been lower in earlier years (e.g. 256), but if a compiler couldn't process a source file that could be printed on
'any' line printer of the day, it must be classified as a toy compiler. (Besides, for EOL comments, the compiler sets no limits - the preprocessor strips off all comments, EOL or otherwise! So the limitation would be in the preprocessor, and I doubt very much that it had any limit affecting EOL comments.)

A note from modern times (5-6 years ago): The company I worked for was revising its C coding rules. The working group had suggested that all source files be limited to a maximum of 80 characters. At the meeting where this proposal was presented, my project leader immediately jumped up and declared that our project would have an exemption from this rule. The main reason: We had rules for generating names of #define constants that frequently lead to names exceeding 80 chars!

Personally, I would have preferred that no exemption were given, forcing us to revise those horrible name generating rules! That didn't happen; the entire 80-char limit was dropped, the name generating rules kept unchanged. The good thing is that I could continue writing EOL comments from col 70.

Message Closed

modified 15-May-23 19:06pm.

Technology has become so far advanced. These days there is no need for coding. AI has already replaced coders and developers.So there is no need for any more computer dictionaries and related things you can just google it, youtube it. We are all free now.

Caveat Emptor.

"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long

It's called "learning".

Hi All,

This is odd I posted a question Friday answered it my-self (rubber ducks are useful) and get a reply from a member
that ends with

Quote:
'Not from me': Oh yes from you. Please have a look to that crap piece of code. I'm pretty sure you have commented such crap for a new member much more directly

I have never answered a question in the 'style' he or it suggests, I am merely posting it here so the flame war can be more visible. I am not generally a 'softy' I tend to work on hardware more. I also think coming up with 'You should know better' of course I should, it does not need that attitude. Even newbies who ask questions should be treated with respect. If you don't know, you don't know, ask someone thats how Steg the cave man inveted the wheel. I'm guessing the Posted is an 'arm chair general' of the software world, knows attacking Stalingrad is a bad idea after there has been a route. Bile duct empty. Resume normal service. $Shucks | :-\$
Also I forgot the gem:

Quote:
And you even don't get that it is better to reply to a comment using the 'reply button' of a comment

When I replied to his comment using the reply button. I'm getting some pop corn...

Trolls gonna troll.

Of course,

Quote:
The code I suggested is simply: simple and logical and correct

"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"

Quote:
The code I suggested is simply: simple and logical and correct Wink |

After the solution has been found and the question answered. Arm Chair Code Warrior!

modified 22-Apr-23 17:44pm.

As we've seen throughout the past six or seven years, some people are just a**holes.

Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver

The person in question is usually OK. And to be fair to him, there was quite a bit of information missing from the original question.

Fair enough, the thing that got me was I had sorted it out, marked it as solved then get a 'learn to program reply' thats what ticked me off, Stack Overflow ended up being full of those types. Also implying I knew nothing of the Boolean logic of an if() statement! He did miss the classic 'why not a switch statement' which is what I was expecting...(I couldn't use one due to the size I was getting the code into). It was just the attitude I found odd...

glennPattonWork3 wrote:
It was just the attitude I found odd...

Yes, I don't really understand why he took that attitude to your solution. Chalk it up to experience and move on, as they say.

Well I wasn't really going to anything else, just wanted to high light it as I feel thats how SO started to circle the drain Smile | :)

glennPattonWork3 wrote:
Even newbies who ask questions should be treated with respect

You must be new to the internet and online forums?

Years (decades) ago when 'forums' were very primitive I remember being very surprised when an author of several books that I depended on tore into a newbie in a long tirade which basically boiled down to RTFM. Make me look more closely at other posts by that same person and noted similar posts. This is the person that I would have expected on that forum to be the absolute authority on the subject. Yet seemed more important to him to tell people not what to post.

Quote:
You must be new to the internet and online forums?

No I am not (thankfully!), it's the first time I had that sort of tirade from a member who I have interacted with in the past. Also CP is one of the few, I feel are beginner friendly web sites the danger is if the people in charge are not aware of this behavior, CP will start to circle the SO drain. I just found the behavoir odd almost like the poster wasn't the poster (a hacked account or worse?)

This is a followup to a previous post made here in the Lounge, that post was titled “Simulation” I think.
The main problem with AI in RTS games is that while the building of the base resembles to what a human would do, the fighting itself follows no strategy. If we take Starcraft for example the AI player combat units always attack following the shortest path, regardless if it’s a case of a building or a unit in it’s own base suffering damage and needing protection or a case of attacking the enemy base. In the later situation the attack force enters the enemy base as stream of units arriving one by one which makes the attack useless.
Among the main challenges in Starcraft is defending the base and the expansions. At the beginning of the game you have a small number of combat units. If you build an expansion, splitting your combat units in two to defend your main base and the expansion is not a good idea, two small unit groups separated from each other are easy to defeat. The solution is to keep your units together and place them in a location that will cover both bases. That can be done by tracing paths from the enemy base to your bases and see where the paths overlap. The place where the common nodes end and the two paths go in different directions makes a good location where you can keep your units. This way you can use your units to protect both bases at the same time

Tactics generally dictate concentrating all your forces on a given point when attacking. Ai can calculate attack and defend strength and arrive at probabilities. Strategy involves iterating over the enemy and finding his weak points, and your own. At its core, it's about maneuvering (march rates; terrain; inclines; fatigue); putting your strength against his weakest point. In real simulations, there are no "barracks" that spawn hundreds of troops at a time or infinite farms: you go for supply (communications) lines.

"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I

>Tactics generally dictate concentrating...

I think that changes a bit depending on the game you’re playing. It is true if you’re playing a game like Warcraft 3. In Starcraft however the main rule is inflict damage without taking damage. That means your attacking units need to be placed not on the edge of the enemy base that is closest to your base ( which is the place where the typical AI sends his units) but somewhere else where they don’t take damage. This can be achieved by marking on the map the areas that fall in the enemy units fire range and keeping your units away from those areas.

Welcome to the Lounge