From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.140.92.236 with SMTP id b99mr4555703qge.21.1463814075144; Sat, 21 May 2016 00:01:15 -0700 (PDT) X-Received: by 10.140.93.45 with SMTP id c42mr221485qge.5.1463814075115; Sat, 21 May 2016 00:01:15 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!11no5440637qgt.0!news-out.google.com!13ni4572qgj.0!nntp.google.com!88no5440667qga.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 21 May 2016 00:01:14 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=83.34.249.176; posting-account=Zsf4jwoAAADEqwCydv835KU9-S3h_Y26 NNTP-Posting-Host: 83.34.249.176 References: <73990fea-e26d-458f-b83c-ecbd24367622@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <55c5001b-af4e-400c-a4fc-86a44d057932@googlegroups.com> Subject: Re: ANN: Introducing AdaBase - Thick database bindings for Ada From: jrmarino Injection-Date: Sat, 21 May 2016 07:01:15 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:30445 Date: 2016-05-21T00:01:14-07:00 List-Id: On Saturday, May 21, 2016 at 3:13:00 AM UTC+2, Jeffrey R. Carter wrote: > If it's one word, then it should be Adabase. CamelCase is antithetical to= some=20 > basic Ada concepts, case insensitivity being one. Remember that many of u= s use=20 > language-sensitive editors that will recapitalize identifiers when we loa= d a=20 > file. Resulting identifiers like Tisokeywords will be difficult to figure= out=20 > and understand. Enough of them may make it difficult enough to use your l= ibrary=20 > that people won't. Artistic licence. I can call it (AdaBase) whatever I want and stylize howe= ver I like. I'll take a look at the types at the top of the package and se= e if underscores makes sense although I don't see why "Tisokeywords" would = case an invasive automatic code-reformatting editor to have fits, unless yo= u mean it must also be all lower case. =20 > I doubt if you can find 2 Ada developers who agree completely on matters = of Ada=20 > formatting, but there is a very broad consensus on something similar to t= he=20 > formatting used in the ARM. (Even there you'll find all-lower-case identi= fiers=20 > in Interfaces.C.) Differing significantly from it will get you some flak = and=20 > some people who will presume that it indicates that you're not very good = at=20 > using the language. Their loss due to poor evaluating skills based on way too little informatio= n, no? A style thoughout a project should be consistent (and looking throu= gh it now I can see AdaBase can improve in this regard, but there was a sev= eral month lag in development that helps explain it), but I don't think the= style has to mimick ARM which I don't think is particularly great, only co= nsistent. > I wouldn't advocate that, though apparently Martin does. While I find som= e of=20 > your formatting irritating, I have used libraries with much worse formatt= ing=20 > (based on looking only at package Adabase). Primarily I was trying to sho= w you=20 > what Martin had objected to. (But I would, if defining the language, make= =20 > CamelCase an error.) Then you'd define that language as case-sensitive, something Ada is not, an= d that's the major flaw in people objection to how capitals are used. Whil= e some people might use weird editors, they also might be in the great mino= rity. =20 > > 2) Suggesting to rename types and enumerations to break all programs > > currently using the library is a much bigger deal and what's the benefi= t? >=20 > I wouldn't suggest that. I would suggest in future using a style closer t= o the=20 > community consensus and putting a little more thought into your names to = make=20 > them clearer and the code easier to read. As you have seen, it would lead= to=20 > greater acceptance of your libraries by others. I seriously doubt anyone beyond beginner would have the slighly issue under= standing the code or understanding the purpose of the variables or types ba= sed on the names. I'll give you the style could be more uniform, and I'll = give you I had no idea of the level of anal-retentiveness about things, but= I will not concede that the quality or readability of the actual code is a= ffected. It seems this situation is the equivalent of moving Rafael Nadal'= s water bottles out of their perfect alignment before he serves -- somethin= g that shouldn't make a bit of differences but is crippling to somebody wit= h OCD. :)