[Vm-dev] coding convention

[Frank Shearar]

On Sat, 5 Jan 2019 at 14:19, Eliot Miranda <eliot.miranda at gmail.com> wrote:

>
> Hi Alistair,
>
> On Sat, Jan 5, 2019 at 1:53 PM Alistair Grant <akgrant0710 at gmail.com>
> wrote:
>
>>
>> Hi Eliot,
>>
>> On Sat, 5 Jan 2019 at 06:19, Eliot Miranda <eliot.miranda at gmail.com>
>> wrote:
>> >
>> > On Fri, Jan 4, 2019 at 9:11 PM Ben Coman <btc at openinworld.com> wrote:
>> >>
>> >>
>> >> What is the preferred coding convention for function definitions...?
>> >> For example...
>> >>
>> >> ...
>> >>
>> >> static int
>> >> convertCopy(char *from, int fromLen, char *to, int toLen, int term)
>> >
>> > Yes please.  Being able to grep for function definitions bu searching
>> for the name at beginning of line is very useful.  Yes, one can use project
>> files to get more convenient searching than find and grep provide, but
>> those are platform specific. If one really wants to search the entire code
>> base across all platforms only find and grep work reliably.  And hence
>> designing coding conventions for those tools, while apparently antiquated,
>> makes solid sense in a complex cross-platform project, IMO & IME.
>>
>> Thanks for explaining this.  I used to use the single line format, but
>> will switch to this now.
>>
>
> Thanks!
>
> > I should perhaps write up the coding conventions I prefer, but in the
>> absence of that, one that I really like is 4-space tabs.
>>
>> I've made some changes to CONTRIBUTING.md, but am waiting to finish
>> testing my .appveyor.yml changes before submitting (tomorrow
>> night probably).
>>
>
> No hurry.  The important thing is that we maintain README.md and
> CONTRIBUTING.md as our culture.  I suggest we add a CODING_CONVENTIONS.md
> and a DOCUMENTATION_OVERVIEW.md, referenced from both README.md and
> CONTRIBUTING.md.  The first is self-explanatory.  The second would be an
> index from topic to location(s).  It can refer to documentation that is in
> the repository, in Smalltalk code, in mailing lists, on web sites
> (including wikis), etc.  But it would not be the documentation itself, just
> a useful index.  We would use it like a scrap book and encourage people to
> put things in it, better that it contains too much than too little.
>
> > What I would really like is a comprehensive list of editors people use
>> and what conventions those editors support for specifying tab stops, if
>> any.  We could then start adding those specifications to platform files and
>> generated files alike.
>>
>> I'm using gvim at the moment, but considering a shift to an IDE, maybe
>> Visual Studio (on linux)?  I'm happy to receive suggestions (it has to
>> be linux, though).
>>
>
> What are the blockers to implementing something in Pharo/Squeak itself?
> I'm guessing needing semantic analysis of the source language.  But if
> instead we simply need string/word-string search, directory hierarchy
> search and line-number/file-name parsing for error messages to map to
> specific lines in files, I would consider implementing something in
> Morphic. I know from harsh experience with VisualWorks' DLL & C Connect
> that maintaining a C parser is an enormous undertaking and in the platforms
> tree we have C, C++, Objective-C, shader languages ?
> (e.g. platforms//iOS/vm/OSX/dtraceOperationsPerSecond.d), M4 macros, etc.
>  (Not to mention unused pascal code.  All in all there are over 80
> different file extensions under platforms, and another 120 under
> processors.  So if semantic analysis is required it is definitely beyond
> our resources.  But if you just want to go from names to textual
> references, that's not hard to build.
>
>
>> Cheers,
>> Alistair
>>
>
> _,,,^..^,,,_
> best, Eliot
>

One step better than a document explaining the desired code conventions is
a .editorconfig (see https://editorconfig.org/) which, in a compliant
editor (VS Code, Visual Studio, Emacs, vim, for example) will punish
malefactors with ugly red squigglies. Er, I mean, gently remind people of
the code conventions that they should follow.

Another thing to think about is the Language Server Protocol (
https://langserver.org/,
https://microsoft.github.io/language-server-protocol/specification) which
establishes a protocol between IDEs and program analyzers. This lets you
add support for your favourite language such that your friend's favourite
IDE can understand your favourite language: go-to-definition, syntax
highlighting, find references, autocomplete, ...

frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190112/12c6a8fc/attachment.html>