[Vm-dev] coding convention

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sun Jan 13 21:05:03 UTC 2019


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)

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/20190113/3d8ec46c/attachment.html>


More information about the Vm-dev mailing list