Naming Conventions

[esgici]

Hi Sudip and Marek,

Thanks to participations

1. 2/3/4 spaces - which do you prefer?

My choice is 3 space; it seems to me 2 is few and 4 is much

2. A good indenting tool (like Edit -> Format current Prg source in xMate)

Never used

I'm setting editor to TAB=4 spaces

I don't like using tab key. Because value (it replace how many space) of tab char may change between editors. Pressing three time space key is more fatiguing than single tab key; by most of editors has ability to positioning cursor to same alignment of upper line when pressed Enter key and this is satisfactory for me.

In my opinion, it causes program is very easy to read and search errors, especially when written with a lot of cases, iterations etc.

Agreed verbatim

--
Regards

[Rathinagiri]

Nice discussions.

I do prefer 3 spaces.

Now coming to remarks.

What do you think about remarks? Should they be included at the module head, variable declaration, important logic, user interface or what?

IMHO, documentation is the boring but required element of programming.

[sudip]

Hello All,

Can you please refer a good tool for indentation or documentation

Thanks in advance.

[Rathinagiri]

PSPad coming along with HMG looks nice.

The difficulties I come across with PSPad.

1. So much of good makes it bad! The auto completion of parenthesis doesn't work properly or as expected when editing an existing line with parenthesis.

2. Multi-line remarks are not differentiated from the normal code. This is a major drawback for me.

Otherwise, PSPad is more than enough for me.

[mol]

I'm using notepad++
I think it's very good text editor.
It keeps indentation, it checks parenthesis (bu it does not add them).

[sudip]

Yes, PSPad is an excellent choice. But, it has some bugs, I hope which will be rectified in the next versions.

Regarding Indentation tools, I used 3 tools
1. xMate editor. Excellent tool. But, problem is that we can't use it alone without a project So, it may not be used with HMG. (If any one has the required .env file for HMG please send me)
2. Code_Reindent. I used this tool. But this tool has very serious bugs. Some times I found my .prg files are truncated
3. One old Clipper tool I found in a clipper web site, which is slow but very secure and does excellent documentation. But I lost this tool

After some time:
Yes, I found them. Please check
http://www.the-oasis.net/files/utils/click203.zip
http://www.the-oasis.net/files/utils/clnclp.zip

[Rathinagiri]

2. Multi-line remarks are not differentiated from the normal code. This is a major drawback for me.

Now I have found that, using shortcut format->add/remove comment for the selected lines adds/removes the comment. It adds '*' each line commenting out. That would also be ok.

[sudip]

Rathi,

Have you tried Ctrl+Shift+A with selected lines with PSPad? It will toggle comment and un-comment lines.

[esgici]

Now coming to remarks.

What do you think about remarks? Should they be included at the module head, variable declaration, important logic, user interface or what?

In my opinion (and coding style) on commenting is: a major necessity of program writing.

Necessity foremost for myself. If commenting disregarded, I couldn't understand my prg wrote before only a few years

And then necessity for my friends, students, co-worker, anyone who I'll demand his help etc.

Should be included

- at the module head? Yes !
- at variable declarations? Yes!
- important logic? Yes!

in short: at everywhere !

Since commenting is a sub topic of coding style, we can pose same measure : "How commented you like programs came to you for read; comment your program that way."

But what, we have some points to emphasize:

- Don't exaggerate! If so, your code may lost, become unnoticeable in crowded remarks
- Remarks must be clear, meaningful and needful.

For example :

This is needless:

Code: Select all

     USE MYTABLE // Open database file

Instead may be :

Code: Select all

     USE MYTABLE // Open customer table

( In fact, there is a "Naming" problem here. MYTABLE isn't a good file name. Names must externalize its content)

In other hand, "module head" remarks has a special importance : When compiled adequately written module head remarks, this will be a sufficient software documentation

I'm using a special way for commenting: put module explanation in a single sentence at first line of module; for example:

Code: Select all

PROC MsgMulti(;                               // Build a message with multiple value in any type
               xMesaj,;
               cTitle )

And when I run DBMList, I get a explained module list

I'm afraid that I'm talking about known issues

Regards

--

Esgici

[Rathinagiri]

Thanks a lot Esgici. I appreciate a lot!