Kevin Powick
Dawn Wolthuis
local variables: lowerCamel, occasionally (but rarely and in our case
only for "record objects") lower.case, previously we permitted
alllowercase for narrow-scoped variables, so we might have profileid
or profilename, for example, but those are now profileId and
profileName.
file field names, UpperCamel
client-side functions: lowerCamel()
server-side methods: UpperCamel()
server-side MV classes (using Cache'): PackageName.UpperCamel
server-side subroutines: UpperCamel or UPPER.CASE (we have been
inconsistent on this front, with even some lowerCamel in the mix)
reserved words in the language: lowercase
contants: UPPER_CASE but inconsistent right now
we do not use equates because we read records in as objects now for a
variety of reasons.
Good question. I would like to see most new MV BASIC code written with
this more contemporary styling rather than UPPER.CASE.NAMES
everywhere. When I see new code written that way, I think "this
language is ancient and so am I" and I don't want to think that way.
cheers! --dawn
> --
> You received this message because you are subscribed to
> the "Pick and MultiValue Databases" group.
> To post, email to: mvd...@googlegroups.com
> To unsubscribe, email to: mvdbms+un...@googlegroups.com
> For more options, visit http://groups.google.com/group/mvdbms
--
Dawn M. Wolthuis
Take and give some delight today
Kevin Powick
On Wednesday, 29 February 2012 18:34:52 UTC-5, Dawn Wolthuis wrote:
file field names, UpperCamel
client-side functions: lowerCamel()
server-side methods: UpperCamel()
server-side MV classes (using Cache'): PackageName.UpperCamel
server-side subroutines: UpperCamel or UPPER.CASE (we have been
inconsistent on this front, with even some lowerCamel in the mix)
reserved words in the language: lowercase
contants: UPPER_CASE but inconsistent right now
Dawn Wolthuis
conventions are a bit more VB-like. The UpperCamel() server-side
methods compared to lowerCamel() javascript are Cache' conventions, so
we adopted them for consistency reasons.
We use Cache' studio for editing, which does color coding of MV BASIC
code, but does not make consistency suggestions (but does have other
assists). --dawn
Symeon Breen
Pretty much use lowerCamel in all languages, in databasic I uses dotted variables to denote related variables oop kinda style
e.g.
READ customer.record FROM customer.file, customer.ID THEN
salesArray = customerRecord<13>
salesArray.count = DCOUNT(salesArray,@VM)
END
--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1424 / Virus Database: 2113/4842 - Release Date: 02/29/12
Martin Phillips
Hi Kevin,
The issue of coding style pops up frequently and usually ends up in disagreement because everyone has their own style rules. My thoughts are that consistency is more important than the actual style adopted.
My personal preference is to write in lowercase with equate token names in uppercase (very much like you).
I also adopt a few conventions about variable names such as using a .f suffix on file variables.
Because we write code that at times has to run on multiple platforms, we have to impose a few rules on structuring code to avoid problems from different interpretation. For example, a construct such as
if rec # “” then write rec to log.f, log.id
else delete log.f, log.id
means something totally different on UniVerse than elsewhere because UV’s WRITE statement has an optional ELSE clause.
As a slightly related point, multi-platform code that cannot be resolved simply by structural style is simplified by use of $ifdef conditional compilation. Sadly not all mv platforms support this, though it is easy to write a pre-processor for those that don’t. In QM, we have an automatically defined token that allows
$ifdef QM
…QM specific stuff…
$else
…non-QM stuff…
$endif
I really wish that the other platforms that support $ifdef would provide a similar token.
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England
+44 (0)1604-709200
Dawn Wolthuis
line is more important than precisely what the standard is. One thing
I would like to see is that with new MV BASIC we start changing the
ALL.UPPER, which is contrary to industry standards in so many ways
(the dot and the all upper case) to a moreStandard way of writing
contemporary software. At least removing the dot helps with
projections of the metadata for other environments.
Of course there is no one right set of standards because "the good
thing about standards is that everyone can have their own" and "the
good thing about standards is that there are so many to choose from."
cheers! --dawn
> --
> You received this message because you are subscribed to
> the "Pick and MultiValue Databases" group.
> To post, email to: mvd...@googlegroups.com
> To unsubscribe, email to: mvdbms+un...@googlegroups.com
> For more options, visit http://groups.google.com/group/mvdbms
--
David Morris
case for all out client stuff (90% of which is in Java with a
smattering of ASP, PHP and Javascript) all our mv code is all upper
case.
I must start taking the caps lock off...
--
David Morris
blog: http://www.brassedoff.net/wp
twitter: @brassedoff
email: da...@brassedoff.net
Chris Long
All of our new code is written with variables in dotted lower case. This helps them to stand out amongst upper case functions and statements.
Subroutine names, internal and external, are all caps. We have started to use underscores to separate words in external subs so that it doesn’t conflict with the dot operator in javascript.
I like to use plenty of whitespace for ease of readability, especially in helping to horizontally align related statements. For example, in CASE statements or several lines of variable assignments.
I am interested in hearing how others name internal subroutines.
Chris Long
RA Services
From:
mvd...@googlegroups.com [mailto:mvd...@googlegroups.com] On Behalf Of Kevin Powick
Sent: Wednesday, February 29, 2012
6:17 PM
To: mvd...@googlegroups.com
Subject: [mvdbms] MV BASIC coding
style
Just wondering what people are using for coding style in MV BASIC these days.
--
Dawn Wolthuis
some well-accepted and well-communicated industry standards for Java,
which I think is really helpful for developers. They do not have to
argue about whether a variable name would be lowerCamel or UpperCamel,
for example. Class names are UpperCamel and method names are
lowerCamel. We adopted java standards where feasible, but our
environment (Cache') has a lot of code in examples and libraries that
has more of a VB style, it seems, and suggests some standards (such as
the UpperCamel for server-side methods standard for our AJAX pages).
For JavaScript, Douglas Crocker is the standards guy with his jslint
product. I run all js code through jslint, even if tweaking his
parameters slightly off from the defaults. He does not have Tolerate
++ and -- as the default, for example, because he doesn't like using
i++. I prefer it to i += 1 or i = i + 1 so I check to Tolerate this
syntax. jslint.com tests for white space as well as more typical
syntax checking.
I would love to have a "lint" program for our MV BASIC code too,
especially if we could make sure to tailor it to our standards (as
with jslint). Because mvbasic is a compiled language, it might not be
as important as for js, but it would still be great for teams where
each person comes with a different background and it can be hard to
communicate standards effectively in other ways. It would be great if
lint programs were built into our environment as it can be in other js
editors. I have not seen variable names and casing addressed with lint
programs, however (although I'm guessing there are some). Details,
details.
cheers! --dawn
--
George Gallen
OOOH... This one bit me big time on Prime Information, except I was using
if condition then write record else release record
Took quite awhile to figure out why my locks were not releasing, and people's terminals kept locking up!
From: martinp...@ladybridge.com
To: mvd...@googlegroups.com
Subject: RE: [mvdbms] MV BASIC coding style
Date: Thu, 1 Mar 2012 09:02:54 +0000
Kevin Powick
On Thursday, 1 March 2012 04:02:54 UTC-5, Martin Phillips wrote:
My thoughts are that consistency is more important than the actual style adopted.
Dawn Wolthuis
Typed on a mobile keyboard
--
Kevin Powick
On Thursday, 1 March 2012 09:41:58 UTC-5, Dawn Wolthuis wrote:
I would love to have a "lint" program for our MV BASIC code too,
especially if we could make sure to tailor it to our standards (as
with jslint).
Mecki Foerthmann
It's easy to introduce new standards with a new language but next to impossible to do that with one that has been around for a long as Pick Basic.
Don't get me wrong, but why throw a piece of code away and re-write it if works perfectly fine?
You add new functionality and enhance it, but you don't re-write all of it.
Who is going to re-write hundreds or thousands of programs just to change variable names from ALL.UPPER to lowerCamel or UpperCamel?
Or even more important, who is going to pay you for doing it?
And so you adopt the standard all the old code was written with.
And if that is all upper case except for comments then I won't start using anything else.
90% of my work is maintenance. Adding new functionality to existing programs is what I do most of the day.
And some of these programs seem to be at least 30 or even 40 years old - numeric labels, dozens of gotos and all that stuff we love to hate these days.
So when I really get the chance to write a new program from scratch I do it in a way that the code looks and feels like the rest of the package.
It is as simple as that!
Dawn Wolthuis
one badly in need of consolidating standards that one would consider
changing standards.
My thinking was that if we do not move forward in changing the
approach to writing MV BASIC for new code, we perpetuate the
positioning of MV as only for existing/old software, rather than also
a part of the future of software development. So, it makes some sense
to me to share best practices from existing software and also suggest
some for new software.
There are some constructs that are pretty standard across many
languages, such as "if" written that way. If you have existing
software with "IF" instead of "if" then go with that, but if you are
starting from scratch (not many are doing that, but that is part of
the point) then I would write it as "if." Make sense? --dawn
--
Tony Gravagno
Martin, everything I do these days is cross-platform, so I use XBASIC by Kevin King.
http://precisonline.com/free.html
Last month I submitted a number of changes for that great FOSS back to Kevin, so anyone who is already using it should get an update.
Code looks like this:
#IF QM,UD,UV
* Code specific to those platforms
#END
#IF D3,R83,AP
* Something different
#END
#IF JB
* Something more unique
#END
That does not replace the functionality of $ifdef, but can be used to ensure that $ifdef is recognized for QM and ignored elsewhere.
The platform tags are arbitrary but I’ve adopted the above. Where required I sometimes use UVI and UVP to distinguish between Universe in Information flavor and in Pick flavor. *sigh*
Regards,
T
Mecki Foerthmann
But the version of UniData (5.2 for Solaris) I work with day in day out
obviously doesn't support lower case syntax.
There might be a switch somewhere to turn case sensitivity off but I
won't touch it.
I've made some nasty experiences with data when case sensitivity was
turned off.
"if a = b then c = a else c = b" won't compile and therefore would
simply not run on the machine at my place of work.
While "IF a = b THEN c = a ELSE c = b" will compile and work just fine.
So for compatibility I would suggest to use upper case for all MV Basic
keywords.
What use is it when your code looks like java but doesn't run on all MV
platforms/flavours?
And especially the "if" has so many different syntaxes that it's not funny.
What about "a == b ?: c = a: c = b" , which is the only conditional
code Microsoft t-sql will allow?
Dawn Wolthuis
doing much cross-platform work. I knew there were some differences
with D3 and Pick related to case sensitivity, but I did not know that
other flavors did not support "if" instead of "IF". Ah well, at least
when I have students work on our application, they think that we are
using some funky old-fashioned language, but they do not think it is
so far afield other than the lack of { } for blocks. If it were all
caps, I would be embarrassed to be writing new software in the
language. Nuttin' is as straight-forward as one might like, eh?
Cheers! --dawn
--
Jeff K
Dan McGrath
option on the BASIC compiler. I could not tell you what version it
first appeared, but I suspect it was *at least* as far back as 6.
If you don't want to option the manuals, you can always use 'HELP
BASIC' at ECL and page down to the options to confirm if your version
of UniData supports the -I option.
Mecki Foerthmann
that's a lot better than turning case sensitivity off.
The downside of course is that once you start using this you have to
compile all programs with the -I option.
I normally use FIBC in AE to compile a program (I guess there is a
switch for that somewhere too) but when I am debugging I use BASIC -Z2.
Well, and then of course there is what Jeff said...
chandru murthi
UPPERCASE code and declare it 'old fashioned' when it's code for a
quintessentially ancient database? Why would you care?
Personally, I use capitals for the language and lowercase for local
variables, uppercase for Common vars, which I find easy to read. I
detest (deTest?) camelCase, though I did not know until this thread
that CustRec is actually a variant, which I do use. camelCase is ugly.
I do, however, agree that dotted names, which I still use, should go.
On the IF issue, I'd strongly recommend anything other than a simple
statment following the test be blocked (ie IF x=1 THEN GOSUB Fixit is
ok), and also not use ELSE w/o an END which some compilers allow.
(OK, OT:) As long as we're on this, another thing I detest is the
habit of placing the { at the end of the line instead of at the
beginning of the next line. If you do the latter, visually matching
{ and } is easy (assuming you block it correctly).
function Mine(var1,var2)
{
.....
}
There are, however, more subtle points in 'standards' that I use. For
example:
-- never define a reused constant in more than one place, use an EQU
instead.
-- place EQUates at the top of the program
-- If there's some complex calculations
( length=LEN(var1)+LEN(var2)-2+adjustment ) assign it once to a
variable and resuse instead of repeating the calculation.
-- If your blocks go more than (say) 5-6 deep, break out the deep-
nested code into its own GOSUB.
-- In general, keep major blocks less than 45 lines deep (well, that's
because my typical edit sessions show about 50 lines on the screen);
use GOSUBs if deeper.
-- etc.
Chandru
On Mar 1, 5:30 pm, Dawn Wolthuis <dw...@tincat-group.com> wrote:
> Oh, wow, good point. Thanks for that tidbit. I obviously have not been
> doing much cross-platform work. I knew there were some differences
> with D3 and Pick related to case sensitivity, but I did not know that
> other flavors did not support "if" instead of "IF". Ah well, at least
> when I have students work on our application, they think that we are
> using some funky old-fashioned language, but they do not think it is
> so far afield other than the lack of { } for blocks. If it were all
> caps, I would be embarrassed to be writing new software in the
> language. Nuttin' is as straight-forward as one might like, eh?
> Cheers! --dawn
>
>
>
>
Dawn Wolthuis
I do not use it because I have always used it (I haven't). I use it because I surveyed the options and decided it was better than other options. Now that there are new choices on the NoSQL front, MV vendors have new competition but also potentially a new sandbox. Why should a brand new nosql dbms be a better choice to back a web site than a seasoned one? If 24-7 is lacking, then fix that (eg) and get in there and make the products better. I am an advocate for any mv vendor investing in the future and looking for new markets. A look at the code by a prospect could be the point where the deal is lost, however.
So, if you want to see MV as only in the past then no one needs to make any effort to move the language forward or even brush it up, but otherwise let's look to the future while building on the past.
I am using Cache'. They went through the work if enhancing the language for OO. I'm willing to additionally write to more industry standard casing to help move it forward.
Regarding { at the end of a line, that is a standard for js that I actually went through our js a while back and changed. I had watched one of Douglas Crocker's talks where he explained why he considered this a best practice in js. It is because of the return syntax where if you do not put the { on the same line, the interpreter will assume a ; is missing and will do the return. Since you must put the { on the line with the return his take is that it is a best practice to do everywhere. Because the editor I use shows matching braces and I am anal about indentation I have been surprised that aligning with jslint on this matter has posed no hardship. As happens with standards, now I like this approach better. --dawn
Typed on a mobile keyboard
Kevin Powick
On Thursday, 1 March 2012 22:31:03 UTC-5, chandru murthi wrote:
I detest (deTest?) camelCase, though I did not know until this thread
that CustRec is actually a variant
George Gallen
is a time when while debugging, I've not Capitalized the Middle letter.
I still use it, but since the language is case sensitive, it does make for
one more step I need to check, especially if I'm using a monitor that
is smaller in size.....
As for UV, we still use all CAPS, mostly because the rest of the software
is, and we wouldn't want it to feel outcasted and different.
Date: Fri, 2 Mar 2012 05:54:58 -0800
From: kpo...@gmail.com
To: mvd...@googlegroups.com
Subject: [mvdbms] Re: MV BASIC coding style
Dawn Wolthuis
which I typically write as UpperCamelCase, compared to lowerCamelCase.
In response to Chandru's comment, I'll admit that I really did not
like this silly way of writing words at first, but now it is second
nature and I even think that it is easier to read when eyeballing it.
There are studies that say that it is easier for people to read upper
and lower text than all upper, so it would make some sense that camel
case might also be easier to eyeball than all upper. However, it is
harder to see that a variable was written with incorrect casing at
times. When working with a language that does not have strong typing,
this carries some downsides with it, but the scales tip toward the
future and aligning more with industry standards for me. I recognize
that others will have other approaches. --dawn
Kevin Powick
On Friday, 2 March 2012 09:50:41 UTC-5, Dawn Wolthuis wrote:
Yes, but today it is more commonly referred to as "upper camel case"
chandru murthi
On Mar 2, 8:16 am, Dawn Wolthuis <dawnwolth...@gmail.com> wrote:
> When I am thinking to the future, I see no good reason that MV should be relegated to the ancient heap. As if any other product if vendors invest to move it forward it could be an excellent choice moving forward. If it is stagnant so all monies come from those who uses it in 1988, then it will go in the opposite direction.
observer that MV BASIC is not "modern."
>I am an advocate for any mv vendor investing in the future and looking for new markets. A look at the code by a prospect could be the point where the deal is lost, however.
(admittedly short) stint in the selling-software world. Besides, the
vast disconnect between the presently favored formats of OO coding, a
subject I will not get into for fear of being OT-chided again (though
I would love to talk about it), and our "linear" form clearly
underlines the old-fashioned-ness of MV code. Using lowercase names
and skipping dots won't soothe these new coders.
> I am using Cache'. They went through the work if enhancing the language for OO. I'm willing to additionally write to more industry standard casing to help move it forward.
without violating my own standards too much.
> Regarding { at the end of a line, that is a standard for js that I actually went through our js a while back and changed. I had watched one of Douglas Crocker's talks where he explained why he considered this a best practice in js. It is because of the return syntax where if you do not put the { on the same line, the interpreter will assume a ; is missing and will do the return. Since you must put the { on the line with the return his take is that it is a best practice to do everywhere. Because the editor I use shows matching braces and I am anal about indentation I have been surprised that aligning with jslint on this matter has posed no hardship. As happens with standards, now I like this approach better.
I've *always* set the { on the next line and there's been no problems.
Crocker's fulfilling his name, imo ;). And color-matching the { & }
does not replace the simpler, and far more intuitive, visual columnar
matching if you use my syntax.
--dawn
>
> Typed on a mobile keyboard
Dawn Wolthuis
MV DBMS before that could use one in the future. So, these prospects
would be developers, VARs, SaaS companies, etc. Before choosing any
environment, someone who is part of the selection process is likely to
have some clues about how they will be doing development, typically
after a trial period. During that trial period, for anyone new to the
language, they are likely to take note of both the lack of braces and
the all upper case. The former can be understood as simply the syntax
of this particular language. The latter can only be explained in much
more bleak terms, indicating not only a old and seasoned product, but
an old and stagnant product. The language in DOTTED.UPPER.CASE is
wearing mom jeans. Let's give that mom at least a bit of a makeover.
I'll have to check the rationale on the end-of-line { again, but
obviously this is still one of those nit things. I switched and have
no reason to go back on it -- now I have fewer lines of code ;-)
There are pros and cons either way, but whatever Crocker said in the
video I watched (hard to search for words in a video) made sense to me
at the time. Cheers! --dawn
> --
> You received this message because you are subscribed to
> the "Pick and MultiValue Databases" group.
> To post, email to: mvd...@googlegroups.com
> To unsubscribe, email to: mvdbms+un...@googlegroups.com
> For more options, visit http://groups.google.com/group/mvdbms
--
Mecki Foerthmann
So what are these braces good for anyway?
Put a * in front of it and you can place them anywhere you want if you
think it makes the code more readable. ;-)
If you don't like dots in variable or program names? Don't use them!
You don't have to use dots but unlike their language you can if you want to.
I like MV Basic.
The syntax is simple, easy to learn and much more readable than these
collections of subroutines - oops sorry, methods or whatever the latest
buzz-word is - they call programming languages these days.
We have got the superior database and if they don't like our language -
tough luck!
And BTW I use all upper case for keywords in SQL as well.
I reckon it makes the code much more readable.
Nobody is keen to learn a new language with a new database.
So unless you change MV Basic to allow vb, java, c-whatever and any
other language there is syntax, they'll always complain that it isn't
exactly like their favourite language.
Or are you suggesting that we should dump MV Basic for something
inferior every time some other language is declared as the new "industry
standard"?
Gene Buckle
BTW Kevin, the MVSP protocol is dirt simple and would be easy to
implment natively in Delphi.
(sorry for the topic drift!)
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!
Buying desktop hardware and installing a server OS doesn't make a
server-class system any more than sitting in a puddle makes you a duck.
[Cipher in a.s.r]
Kevin Powick
On Friday, 2 March 2012 12:07:17 UTC-5, geneb wrote:
BTW Kevin, the MVSP protocol is dirt simple and would be easy to
implment natively in Delphi.
Martin Phillips
Hi Kevin,
> I'd much rather have the QMClient protocol for another little project.
> I tried to packet sniff it once, but must have dones something wrong
> with the analyzer I was using because I didn't see much.
The QMClient protocol is not public. It has also changed significantly since the open source release, including encrypting the data.
Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England
+44 (0)1604-709200
Dawn Wolthuis
> Come on Dawn this is getting silly.
> So what are these braces good for anyway?
> Put a * in front of it and you can place them anywhere you want if you think
> it makes the code more readable. ;-)
Of course! I was responding to Chandru who has an aversion to one
style that is pretty close to being the JavaScript standard. So, I
explained that I had switched from the braces in the same column
approach to the Crockford standard. Neither is right or wrong, they
are just different.
> If you don't like dots in variable or program names? Don't use them!
Agreed.
> You don't have to use dots but unlike their language you can if you want to.
Yes, and for code that uses that as a standard, I would maintain it in
the same way. I would suggest that it would be wise if starting a new
product line to keep dots out of variable names for reasons I have
mentioned. I realize others might disagree.
> I like MV Basic.
> The syntax is simple, easy to learn and much more readable
I definitely agree! I think it would be a shame for it to be
discounted for unnecessary reasons like DOTTED.VARIABLE.NAMES.
> than these
> collections of subroutines - oops sorry, methods or whatever the latest
> buzz-word is - they call programming languages these days.
> We have got the superior database and if they don't like our language -
> tough luck!
Yes, I definitely understand. My thinking is more related to possibly
getting new MV VARS/SaaS companies writing applications in MV. That
might be overly optimistic, but I think it is feasible to raise the
industry up to where it could compete in the NoSQL space.
> And BTW I use all upper case for keywords in SQL as well.
> I reckon it makes the code much more readable.
I suspect most SQL out there is written with all upper case keywords at least.
> Nobody is keen to learn a new language with a new database.
> So unless you change MV Basic to allow vb, java, c-whatever and any other
> language there is syntax, they'll always complain that it isn't exactly like
> their favourite language.
I have introduced 4 students to MV over the past few years. Making
this one change of writing with more OO-like casing standards has been
helpful, even if they still think the language is old-fashioned. They
realize it is pretty similar to JavaScript in many respects.
> Or are you suggesting that we should dump MV Basic for something inferior
> every time some other language is declared as the new "industry standard"?
By no means. If I didn't like it, I would have no reason to care if it
had any makeovers or not. I'm not suggesting anything that would not
be backward compatible. I like having it enhanced for OO and with the
ability to write with similar variable names to JS, Java, C#, etc. but
I definitely understand that there is no reason to take existing code
and convert it in this way. I hope that helps clarify. cheers!
--dawn
--
Gene Buckle
>> BTW Kevin, the MVSP protocol is dirt simple and would be easy to
>> implment natively in Delphi.
>>
>
> If I was using D3 v9.x I would take a look at it. I'd much rather have the
> QMClient protocol for another little project. I tried to packet sniff it
> once, but must have dones something wrong with the analyzer I was using
> because I didn't see much. I only spent a very short time on it though.
>
If you don't want to go rummaging through the source code, I'd recommend
using WireShark. It's a very good packet sniffer for windows.
Tony Gravagno
> a subject I will not get into for fear of being OT-chided again
(though I
> would love to talk about it)
Chandru, we had a long discussion here about the role of managers.
Managers will only moderate for abuse like spam and porn, not topical
content - and that means there will be no management requests
regarding the organization of your content. The forum is yours, post
as you will.
My personal preference, to avoid long threads which are difficult to
search for focused content, is for different topics to be in different
threads. I don't think that's an unreasonable opinion. And that's not
a manager speaking, that's just one man's opinion amongst a couple
hundred others. Regard it as you will.
Regards,
T
Kevin Powick
On Friday, 2 March 2012 14:38:17 UTC-5, Martin Phillips wrote:
Hi Kevin,
The QMClient protocol is not public. It has also changed significantly since the open source release, including encrypting the data.
Dawn Wolthuis
his name is Douglas Crockford. That's what I get for not proofreading.
I'm sure there are other mistakes too, but thought I better correct
this one. Cheers! --dawn
On Thu, Mar 1, 2012 at 8:41 AM, Dawn Wolthuis <dw...@tincat-group.com> wrote:
> I did some Java development a while back and taught Java. There are
> some well-accepted and well-communicated industry standards for Java,
> which I think is really helpful for developers. They do not have to
> argue about whether a variable name would be lowerCamel or UpperCamel,
> for example. Class names are UpperCamel and method names are
> lowerCamel. We adopted java standards where feasible, but our
> environment (Cache') has a lot of code in examples and libraries that
> has more of a VB style, it seems, and suggests some standards (such as
> the UpperCamel for server-side methods standard for our AJAX pages).
>
> For JavaScript, Douglas Crocker is the standards guy with his jslint
> product. I run all js code through jslint, even if tweaking his
> parameters slightly off from the defaults. He does not have Tolerate
> ++ and -- as the default, for example, because he doesn't like using
> i++. I prefer it to i += 1 or i = i + 1 so I check to Tolerate this
> syntax. jslint.com tests for white space as well as more typical
> syntax checking.
>
> I would love to have a "lint" program for our MV BASIC code too,
> especially if we could make sure to tailor it to our standards (as
> with jslint). Because mvbasic is a compiled language, it might not be
> as important as for js, but it would still be great for teams where
> each person comes with a different background and it can be hard to
> communicate standards effectively in other ways. It would be great if
> lint programs were built into our environment as it can be in other js
> editors. I have not seen variable names and casing addressed with lint
> programs, however (although I'm guessing there are some). Details,
> details.
>
> cheers! --dawn
>
> On Thu, Mar 1, 2012 at 8:27 AM, Chris Long <cl...@raservicesbilling.com> wrote:
>> All of our new code is written with variables in dotted lower case. This
>> helps them to stand out amongst upper case functions and statements.
>>
>>
>>
>> Subroutine names, internal and external, are all caps. We have started to
>> use underscores to separate words in external subs so that it doesn’t
>> conflict with the dot operator in javascript.
>>
>>
>>
>> I like to use plenty of whitespace for ease of readability, especially in
>> helping to horizontally align related statements. For example, in CASE
>> statements or several lines of variable assignments.
>>
>>
>>
>> I am interested in hearing how others name internal subroutines.
>>
>>
>>
>> Chris Long
>>
>> RA Services
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ________________________________
>>
>> From: mvd...@googlegroups.com [mailto:mvd...@googlegroups.com] On Behalf Of
>> Kevin Powick
>> Sent: Wednesday, February 29, 2012 6:17 PM
>> To: mvd...@googlegroups.com
>>
>>
>> Subject: [mvdbms] MV BASIC coding style
>>
>>
>>
>> Just wondering what people are using for coding style in MV BASIC these
>> days.
>>
>>
>>
>> Personally, my style has changed over the years. In the "old days", it was
>> all upper case with dotted variable names. Since most MV implementations
>> have handled mixed case for years, and I use a few other languages, my style
>> has changed to make working between languages as similar as possible So,
>> today I'm using:
>>
>>
>>
>> lower case statements: open 'my-file' to my.fl else ...
>>
>> dotted variable names: my.fl, total.sales.
>>
>> capitalized and underscored equates: equ CUST_NAME to cust.rec(5)
>>
>>
>>
>> The most recent change has been for equates, mostly because they are
>> somewhat akin to constants represented in other languages the same way.
>> They really stand out in the lower-case code. However, I'm not 100%
>> certain I love it, yet.
>>
>>
>>
>> So, what's your style?
>>
>>
>>
>> --
>>
>> Kevin Powick
Martin Phillips
> Ah, the encryption was probably the issue. Is this proprietary or is a
standard,
> well-know encryption used? Just wondering what I would need to tell a
client
> doing a security audit.
It is 128 bit AES. For obvious reasons, I'm not going to say how the key is
derived.
> It seems a little odd to me that on-the-wire encryption would be done for
the QMClient
> by default. Connections such as Telnet are not encrypted. I would of
though
> that if people want security they use SSH, SSL/TLS, etc.
My perception is that there is a move towards SSH. Indeed, some Linux
systems seem to make it hard to get telnet working at all.
Our view was that in today's security conscious world the protocol should be
secure by default. There is an option not to encrypt, perhaps when
everything is on a local network with minimal risk of packet sniffing.
Incidentally, QMNet uses 128 bit AES encryption too. In both cases, this
ensures that we meet security rules required by industry standards when
transmitting things such as records that contain credit card data.
> It's too bad that there is not a public API for low-level communication
with QM.
> I usually use the QM Client libraries, but there are a few projects that
would
> work better without them, for me anyway.
QMClient is the "official" API. I would be interested to know why you would
prefer to work at a lower level.
By keeping the on-the-wire protocol under our control, we have the
flexibility to make changes that would otherwise have users moaning that
their applications no longer worked. QMClient has maintained backward
compatibility since the first release. The two ends of the connection
negotiate regarding what is supported. For example, connections where either
end is before release 2.8-11 will not use encryption. There will be a big
change to the protocol in the release scheduled for mid-April. You will have
to wait to find out why!!!
Kevin Powick
On Monday, 5 March 2012 04:09:42 UTC-5, Martin Phillips wrote:
QMClient is the "official" API. I would be interested to know why you would refer to work at a lower level.
By keeping the on-the-wire protocol under our control, we have the
flexibility to make changes that would otherwise have users moaning that
their applications no longer worked.
change to the protocol in the release scheduled for mid-April. You will have
to wait to find out why!!!
Martin Phillips
Hi Kevin,
> Imagine a native JavaScript library that would allow a web browser client
> to communicate with QM.
There is a Java interface to QM available via the Solutions page of the web site. This is believed to be fully working but it still tagged as being a beta test version.
Our aim is to have interfaces for most common development languages. Some already exist. Others will follow as the needs are identified.
Kevin Powick
On Monday, 5 March 2012 11:34:37 UTC-5, Martin Phillips wrote:
There is a Java interface to QM available via the Solutions page of the web site.
Martin Phillips
Hi Kevin,
I admit to not being a Java user. I was under the impression (based on information received from other sources) that the QM Java API was applicable to JavaScript. Perhaps not.
Martin
--
