coding convention

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

coding convention

Ben Coman
 
What is the preferred coding convention for function definitions...?
For example...

static int convertCopy(char *from, int fromLen, char *to, int toLen, int term)

static int 
convertCopy(char *from, int fromLen, char *to, int toLen, int term)


cheers -ben
Reply | Threaded
Open this post in threaded view
|

Re: coding convention

Eliot Miranda-2
 


On Fri, Jan 4, 2019 at 9:11 PM Ben Coman <[hidden email]> 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)

I loathe this.
 
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.

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.

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.

_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: coding convention

Nicolas Cellier
 


Le sam. 5 janv. 2019 à 06:19, Eliot Miranda <[hidden email]> a écrit :
 


On Fri, Jan 4, 2019 at 9:11 PM Ben Coman <[hidden email]> 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)

I loathe this.
 
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.

Ah, thanks for fleshing those conventions with some meaning, it makes more sense :).
Of course, my O & E differs a bit.
Hovering other the text to see the definition, or just displaying a few lines in an embedded text editor will beat find/grep productivity by large.

image.png

I'm still using grep/find, but not for those trivial things that the IDE can do.
I'm also using the github search in web browser as a complementary tool.

Also the productivity of an IDE shines for inspecting the code starting from a (sub) list of compiler warnings!

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.
 
4-space tabs is the default in many editors nowadays, but I recently saw platforms code depending on legacy 8-space tabs for correct alignment.
I love tab indent, tolerate space indents, hate tab in the middle of text, and hate the mixture of spaces and tabs indent. But I don't always notice, editors are too bright.

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 mostly using VisualStudio and Notepad++ on Windows, XCode on Mac. I'm still using vi or vim when I want well known regex power, or when working with the console.
They all support any tabs stop you like, can indent with tab or spaces etc... It's just a matter of taking time to configure them.
I try to respect the style of original author, but if it's too exotic (like 2 space indent on platforms/win32), and I'm to lazy to reconfigure my editor, I have to fight against it... For this reason, I would prefer to see more uniform conventions.

_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: coding convention

Ben Coman
In reply to this post by Eliot Miranda-2
 


On Sat, 5 Jan 2019 at 13:19, Eliot Miranda <[hidden email]> wrote:
 
On Fri, Jan 4, 2019 at 9:11 PM Ben Coman <[hidden email]> 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)

I loathe this.
 
static int 
convertCopy(char *from, int fromLen, char *to, int toLen, int term)

Yes please. 

Cool.  btw, the reason I ask is that I've been reviewing minheadless and several of the files Ronie copied into minheadless 
he converted from the former to the latter.  To make it easier to diff between these, I'll have a go a converting 
the original files to the same convention.

 
Being able to grep for function definitions bu searching for the name at beginning of line is very useful. 

Ahh, nice trick!   Suddenly I've used that already a few time today.
 

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.

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.

Me too.

 
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 use mostly `vi` because its the most common tool available.  But back when I was doing the MSVC minheadless
it was a comparative real joy clicking back and forth between error messages in Visual Studio to got straight to the related code.
The other Visual Studio feature I discovered that really improved workflow was shading of #ifdef'd out code. 

cheers -ben
Reply | Threaded
Open this post in threaded view
|

Re: coding convention

Alistair Grant
In reply to this post by Eliot Miranda-2
 
Hi Eliot,

On Sat, 5 Jan 2019 at 06:19, Eliot Miranda <[hidden email]> wrote:

>
> On Fri, Jan 4, 2019 at 9:11 PM Ben Coman <[hidden email]> 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.


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


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

Cheers,
Alistair
Reply | Threaded
Open this post in threaded view
|

Re: coding convention

Eliot Miranda-2
 
Hi Alistair,

On Sat, Jan 5, 2019 at 1:53 PM Alistair Grant <[hidden email]> wrote:
 
Hi Eliot,

On Sat, 5 Jan 2019 at 06:19, Eliot Miranda <[hidden email]> wrote:
>
> On Fri, Jan 4, 2019 at 9:11 PM Ben Coman <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: coding convention

Frank Shearar-3
 
On Sat, 5 Jan 2019 at 14:19, Eliot Miranda <[hidden email]> wrote:
 
Hi Alistair,

On Sat, Jan 5, 2019 at 1:53 PM Alistair Grant <[hidden email]> wrote:
 
Hi Eliot,

On Sat, 5 Jan 2019 at 06:19, Eliot Miranda <[hidden email]> wrote:
>
> On Fri, Jan 4, 2019 at 9:11 PM Ben Coman <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: coding convention

Nicolas Cellier
 


Le dim. 13 janv. 2019 à 02:02, Frank Shearar <[hidden email]> a écrit :
 
On Sat, 5 Jan 2019 at 14:19, Eliot Miranda <[hidden email]> wrote:
 
Hi Alistair,

On Sat, Jan 5, 2019 at 1:53 PM Alistair Grant <[hidden email]> wrote:
 
Hi Eliot,

On Sat, 5 Jan 2019 at 06:19, Eliot Miranda <[hidden email]> wrote:
>
> On Fri, Jan 4, 2019 at 9:11 PM Ben Coman <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: coding convention

Frank Shearar-3
 
On Sun, 13 Jan 2019 at 13:05, Nicolas Cellier <[hidden email]> wrote:
 


Le dim. 13 janv. 2019 à 02:02, Frank Shearar <[hidden email]> a écrit :
 
On Sat, 5 Jan 2019 at 14:19, Eliot Miranda <[hidden email]> wrote:
 
Hi Alistair,

On Sat, Jan 5, 2019 at 1:53 PM Alistair Grant <[hidden email]> wrote:
 
Hi Eliot,

On Sat, 5 Jan 2019 at 06:19, Eliot Miranda <[hidden email]> wrote:
>
> On Fri, Jan 4, 2019 at 9:11 PM Ben Coman <[hidden email]> 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.

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
Reply | Threaded
Open this post in threaded view
|

Re: coding convention

Nicolas Cellier
 


Le lun. 14 janv. 2019 à 21:28, Frank Shearar <[hidden email]> a écrit :
 
On Sun, 13 Jan 2019 at 13:05, Nicolas Cellier <[hidden email]> wrote:
 


Le dim. 13 janv. 2019 à 02:02, Frank Shearar <[hidden email]> a écrit :
 
On Sat, 5 Jan 2019 at 14:19, Eliot Miranda <[hidden email]> wrote:
 
Hi Alistair,

On Sat, Jan 5, 2019 at 1:53 PM Alistair Grant <[hidden email]> wrote:
 
Hi Eliot,

On Sat, 5 Jan 2019 at 06:19, Eliot Miranda <[hidden email]> wrote:
>
> On Fri, Jan 4, 2019 at 9:11 PM Ben Coman <[hidden email]> 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