Readability: Difference between revisions

From SpaceElevatorWiki.com
Jump to navigationJump to search
No edit summary
No edit summary
Line 1: Line 1:
I have been looking through the existing Robot code.
I have been looking through the existing Delphi robot code.


At some point I think we should do a bunch of renames.
After the mechanical port, we should do a bunch of renames and cleanup.


I don't know what this variable does:
I don't know what this variable does:
Line 8: Line 8:
I think its name should be obvious. I think the "o" is unnecessary, and I think the rest doesn't tell me what it is. If the Nb means number, that is also not really necessary. We don't have to make variable names long, just make the names as predictable and natural as possible would be great.
I think its name should be obvious. I think the "o" is unnecessary, and I think the rest doesn't tell me what it is. If the Nb means number, that is also not really necessary. We don't have to make variable names long, just make the names as predictable and natural as possible would be great.


Let's use the C# Boundary to make nice type and variable names. The functions seem logical and that is the harder part of designing a boundary API. But making the code so natural that anyone reading it can instantly figure out what is going on, approachability, is important.
Let's use the C# Boundary to make nice type and variable names. But making the code so natural that anyone reading it can instantly figure out what is going on, approachability, is important.


I think we should not do this:
I think we should not do this:
Line 14: Line 14:
       read oRaceTimeBeforeNext;
       read oRaceTimeBeforeNext;


That just wastes space and pollutes the namespace. Lets just expose most things as a data member and also make it a property one day without changing the other code. It gets us nothing. Some languages allow you to write compact code. I think with an afternoon of search and replace across files we could make the Torcs robot a ton better for a random programmer on the street.
That just wastes space and pollutes the namespace. Lets just expose most things as a data member and also make it a property one day without changing the other code. It gets us nothing.


I presume the data for RaceTimeBeforeNext is needed, but it sure sounds like a weird name.
I think with an afternoon of search and replace across files we could make the Torcs robot a ton better for a random programmer on the street.
 
I presume the data for RaceTimeBeforeNext is needed, but it sure sounds like a weird information.


Just imagine if all functions had totally random names. How much would that slow progress?
Just imagine if all functions had totally random names. How much would that slow progress?

Revision as of 22:25, 14 June 2008

I have been looking through the existing Delphi robot code.

After the mechanical port, we should do a bunch of renames and cleanup.

I don't know what this variable does: oPrivGearNb

I think its name should be obvious. I think the "o" is unnecessary, and I think the rest doesn't tell me what it is. If the Nb means number, that is also not really necessary. We don't have to make variable names long, just make the names as predictable and natural as possible would be great.

Let's use the C# Boundary to make nice type and variable names. But making the code so natural that anyone reading it can instantly figure out what is going on, approachability, is important.

I think we should not do this:

  property RaceTimeBeforeNext: Double
     read oRaceTimeBeforeNext;

That just wastes space and pollutes the namespace. Lets just expose most things as a data member and also make it a property one day without changing the other code. It gets us nothing.

I think with an afternoon of search and replace across files we could make the Torcs robot a ton better for a random programmer on the street.

I presume the data for RaceTimeBeforeNext is needed, but it sure sounds like a weird information.

Just imagine if all functions had totally random names. How much would that slow progress?