[Vm-dev] coding convention

Mon Jan 14 20:41:48 UTC 2019

Le lun. 14 janv. 2019 à 21:28, Frank Shearar <frank.shearar at gmail.com> a
écrit :

>
> 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.
>

:) yes, I think that it's what I wrote, but maybe I wasn't clear enough,
thanks for clarifying.

> frank
>
>>
>> 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/09c3c4b2/attachment.html>