OpenEuphoria

1. Best Practices

• Posted by jeremy (admin) Dec 31, 2010
• 2028 views

Thinking about the scope thread going on right now, I wonder if we don't need a lint checker that goes through and ensures best practices. For example, the whole debate about the scope issue is almost non-existant in most code I work on because there are not top level variables. In general top level variables are bad business. Top level constants, yes. Variables? No.

Even if there is not a lint tool, a wiki page wiki:BestPractices could be solving a whole lot of these problems. I propose we begin to create such a page. There is the wiki:CodingConvention page that contains some wiki:BestPractices but there are hundreds of wiki:BestPractices that would not really fall under a coding convention.

I also think that we would need some type of criteria as to what is a best practice and what is a "my style" practice. For example, one may say a best practice is to use camelCaseVariableNames starting with a lower case letter and function/procedures be named camel case starting with an upper case letter SuchAsThis(). I'm not really sure that could be considered a "best practice." There are different naming conventions such as use_underscores. Now is not using variables named a, b, c to mean first name, last name and birth date could be a best practice, i.e. make your variables descriptive and concise.

Jeremy

3. Re: Best Practices

• Posted by DanM Dec 31, 2010
• 2000 views

heh heh heh, yeah! But at the very least, all of us non-professional programmers will get a chance to see quite a variety of "best practices", and even perhaps some of the reasoning behind some of them, both of which should be interesting, and possibly helpful, too.

Dan

5. Re: Best Practices

• Posted by jeremy (admin) Jan 03, 2011
• 1929 views

Simple tasks can have simple interfaces. Complex tasks rarely can have simple interfaces. However:

map args = cmd_parse({ 
    { "o", 0, "Output directory", { HAS_PARAMETER } }, 
    { "v", 0, "Verbose mode" } 
}) 

Is pretty simple for what you get. Full command line parsing including extras, nicely formatted help screens, argument validation (checking ones supplied are valid and erring with usable information when one is supplied that is not allowed, checking that those that require parameters have parameters). If you take the above 4 lines of code and implement that in your program the old fashioned way... It's pretty simple.

Now, where your tip comes into play is having a simple process with a complex interface. That indeed is terrible. I do not think that rule applies, however, to man:std_cmdline#cmd_parse. The docs can look daunting for that method, I agree. Maybe what is needed is a bare bones example up front such as the one above.

Jeremy

Just added ticket:585 which will be part of 4.0.1 release.

7. Re: Best Practices

• Posted by mattlewis (admin) Jan 09, 2011
• 1749 views

Euphoria 4.0 introduced two new scopes:

1. public
2. export

Basically, these allow symbols to be seen only by files that include the file where the symbol resides. A public symbol can also optionally be seen by files that include the file where the symbol resides. The public scope is expected mainly to be of interest to library developers, where it will allow them to spread their code across multiple files, but still be able to present a simple API to their users that requires only a single include statement.

In general, I recommend using the export scope if you require visibility of a symbol in another file. This requires an explicit include statement in any file that uses the symbol, making dependencies clear and easier to understand.

Euphoria namespaces are used only for resolving which symbol to use. They do not create unique scopes like, say, C++ namespaces do.

Matt

9. Re: Best Practices

• Posted by DanM Jan 09, 2011
• 1759 views

My real main point was the hope that experienced/professional programmers would share their REASONS for their "best practices" with us, as well as the "best practices" themselves. That way, we could evaluate for ourselves if their "best practices" make sense to us. But so far I don't think I have seen any actual "best practices". I thought "best practices" were some "useful methodologies" in programming, but perhaps I'm mistaken or confused?

Dan

11. Re: Best Practices

• Posted by jeremy (admin) Jan 09, 2011
• 1648 views

The intent is just that. Now, this thread was to gather some enthusiasm about creating a wiki page to contain best practices. It seems that no one is really interested in it as this thread has very little activity

Jeremy

13. Re: Best Practices

• Posted by bill Jan 10, 2011
• 1527 views

I am thinking of writing something about the work I am doing at the moment. It is not something that is "interesing" but rather an inherently difficult problem that many programmers have to deal with.

The problem, simply stated, is how can we do data entry well? IE how can we ensure the names and addresses entered into a database are correct. The straight answer is we can not. But still we must try.

Discussing the problem is valuable because it is open-ended. No single technique works. Many common techniques (Regular expressions, Soundex, Metaphone, Edit distance ..) help with parts of it, other common techniques lose data unnecessarily.

Do you think this might be worth considering? Perhaps database is a bit mundane.

Personally I might say good practice is "try not to write code, good data design is better than pages of (probably buggy) code.

And again I might say "if the code looks verbose, unclear or defensive start again"