HMGforum.com

fprijatelj wrote: Nothing about style

My answer was to escigi

For your concern, I think that any serious compiler would easily get rid of the == .T. part...

I'm very to read this topic: with other problems we speak about bad syntax.
Anyway, many times I prefer an extended (unusefull?) syntax to show exactly what I means. Many times short syntax creates misunderstanding for a lot of people and I found a lot of this errors.
I never used this IF (a>b) == .T.
Always I prefer "IF ::lCrteated == .T." instead "IF (::lCreated)" ( and this "IF ::lCreate" is wrong: what means? ::lCreate==.T. or ::lCreate==3? You know is a logical var because "l" is used...)
I don't like "RETURN " somewhere (as Esgici write) but it's very usefull in most scenario.
I don't like var name like these: "i", "n", "o", etc when you want to find them.....
I don't like CLIPPER reserved words in lower case
etc., etc.

Cheers

l3whmg wrote:I'm very to read this topic: with other problems we speak about bad syntax.
Anyway, many times I prefer an extended (unusefull?) syntax to show exactly what I means. Many times short syntax creates misunderstanding for a lot of people and I found a lot of this errors.
I never used this IF (a>b) == .T.
Always I prefer "IF ::lCrteated == .T." instead "IF (::lCreated)" ( and this "IF ::lCreate" is wrong: what means? ::lCreate==.T. or ::lCreate==3? You know is a logical var because "l" is used...)
I don't like "RETURN " somewhere (as Esgici write) but it's very usefull in most scenario.
I don't like var name like these: "i", "n", "o", etc when you want to find them.....
I don't like CLIPPER reserved words in lower case
etc., etc.

Cheers

I fully agree.

Many people makes enormous efforts to write smaller code (not necessarily more efficient) that is difficult to read and confusing (even for the author).

Regarding multiple returns, sometimes is more complex and confusing to adjust code to have only one.

Just my two cents.

Rightly said Roberto.

Hi

What sounds better (in English) ?

Are you OK ?

OR

Is it true that you are OK ?

IMHO this is not about style or about shorter/longer code, but about
programming paradigm and about habits.
As I said , it's also a sample of bad habit in lot of books about programming (no offense) .
It's also about consistency (only 2 lines apart somebody changed his mind):
Regards
Franček

Francek,
when HMG4 several people started hacking code... some of them committed the code and then never come back... please have a look at commit history, you will notice that in the last months HMG4 has been enhanced/expanded by me and Luigi, with Mauricio and Rathi. Lately Ricci joined but since he has no commit rights I or Luigi commit his patches.
So the code has been deeply changed and it is possible that when code is added the programmer uses its own coding style... I will try to find Priitpal message where he suggested a coding style.

Anyway, there are several points where HMG4 needs some work. I have some patches "almost ready" that need some more work...
I ported EDIT EXTENDED from hmg3, it was a long work and still needs some polishing... (it's a quite powerful CRUD function)
WHEN/VALID is to be implemented (I also have some basic code to complete)...
some higher-level classes should be implemented...

So, if you really want to help, can you please provide your knowledge and help to complete any of the above points ?

I promise that when HMG4 will be stable, all the == .T. will be removed, I don't like them either...

Any volunteer that wants to join to help complete HMG4 in specific areas ?

Francesco

viewtopic.php?f=32&t=1940

This codestyle is distributed via doc\txt\en\codingstyle.txt

1. Indentation is three spaces and not tab.

2. Variable names should start with the type (c,n,l,d,a,x,o,q as the case may be) as mentioned below in smaller case letter and name of the variable would start with an uppercase letter.
Examples:
cName - variable name 'cName' which is a character type.
nNumber - 'nNumber' variable which is a number type.
lYesNo - 'lYesNo' variable which is a logical type.
dToday - 'dToday' variable which is a date type.
aObjects - 'aObjects' variable which is an array type.
xValue - 'xValue' variable the type of which is not known now and may be known at run time.
oDataObject - 'oDataObject' variable which is an object type.
qPrinter - 'qPrinter' variable which is a QT object type.

3. When calling a QT method/function, the first word is started with a smaller case and next words are uppercase.
Example:
qTreeWidget:indexFromItem( qTreeWidgetItem )

4. A space is necessary between starting and ending parenthesis of function names and the parameters. Please see the example.
Example:
qTreeWidget.collapseItem(qTreeWidgetItem) - Wronge
qTreeWidget.collapseItem( qTreeWidgetItem ) - Right

5. All Harbour keywords must be uppercase: DO CASE IF ENDIF ELSE CASE FOR NEXT etc.

6. Only FUNCTION/METHOD Name must be starting at column 1, rest of the lines including RETURN
must be indented.

7. No short names as FUNC PROC be used, all complete ones.

8. SWTCH and DO CASE and its CASE statements must be on same indent:
...SWITCH x
...CASE 4
...CASE 5
...ENDSWITCH

9. Function call must be like: MyFunc( n, n1, ... ), no space between function name and opening parenthesis.

10. No comments starting with * (star). Only ANSI compatible // some comment OR preferably /* some comment */.

11. Every function body must be separated by a blank line and seperator. Seperator line must be uniform as I have used.

12. HMG library source must be compilable with -w3 switch. It helps to detect the wrong code soon.

13. No LOCAL variable assignment with NIL. It is neither needed not oprimized.

Hi mrduck

So, if you really want to help, can you please provide your knowledge and help to complete any of the above points ?

First let me apologize. I didn't want to offend anybody.
I think that HMG4 and HMG3 are great toolkits. I congratulate to Roberto and all
contributors to this project .
I am currently using HMG3 in some projects.
At the same time i am porting my software to HMG4.
Soon i will send you some patches ( proposals).
Otherwise i am developing web platform.
Server side is in HARBOUR.
Client side is in QooXdoo
http://demo.qooxdoo.org/current/demobro ... _Huge.html

I believe that future is in web technologies.
Even desktop applications will have their UI rendered by browser.

Regards
Franček