[Vm-dev] coding convention

Frank Shearar frank.shearar at gmail.com
Mon Jan 14 20:28:26 UTC 2019

On Sun, 13 Jan 2019 at 13:05, Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

> Le dim. 13 janv. 2019 à 02:02, Frank Shearar <frank.shearar at gmail.com> a
> écrit :
>> 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.
>> +1 !
> It seems we can configure by repository and accomodate to several
> heterogeneous styles without massive reformat commit
> (like ths 8-space tab stops, 2-space indent used in platforms/win32)

You can also do it per directory, so the Windows subdirectory can keep the
2-space indents. Just drop a .editorconfig in the subdirectory with the
properties you wish to override.


> 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/20190114/f6d58b8c/attachment-0001.html>

More information about the Vm-dev mailing list