<div dir="ltr"><div dir="ltr">On Sun, 13 Jan 2019 at 13:05, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">Le dim. 13 janv. 2019 à 02:02, Frank Shearar <<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Sat, 5 Jan 2019 at 14:19, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Alistair,</div><br><div class="gmail_quote"><div dir="ltr">On Sat, Jan 5, 2019 at 1:53 PM Alistair Grant <<a href="mailto:akgrant0710@gmail.com" target="_blank">akgrant0710@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
Hi Eliot,<br>
<br>
On Sat, 5 Jan 2019 at 06:19, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br>
><br>
> On Fri, Jan 4, 2019 at 9:11 PM Ben Coman <<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>> wrote:<br>
>><br>
>><br>
>> What is the preferred coding convention for function definitions...?<br>
>> For example...<br>
>><br>
>> ...<br>
>><br>
>> static int<br>
>> convertCopy(char *from, int fromLen, char *to, int toLen, int term)<br>
><br>
> 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.<br>
<br>
Thanks for explaining this.  I used to use the single line format, but<br>
will switch to this now.<br></blockquote><div><br></div><div>Thanks!</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 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.<br>
<br>
I've made some changes to CONTRIBUTING.md, but am waiting to finish<br>
testing my .appveyor.yml changes before submitting (tomorrow night probably).<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> 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.<br>
<br>
I'm using gvim at the moment, but considering a shift to an IDE, maybe<br>
Visual Studio (on linux)?  I'm happy to receive suggestions (it has to<br>
be linux, though).<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Cheers,<br>
Alistair<br>
</blockquote></div><div><br></div><div dir="ltr" class="gmail-m_8511371709839671375gmail-m_-4325086093176979306gmail-m_5700834663384161568gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div></div></div></blockquote><div><br></div><div>One step better than a document explaining the desired code conventions is a .editorconfig (see <a href="https://editorconfig.org/" target="_blank">https://editorconfig.org/</a>) 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.</div><div><br></div></div></div></div></div></blockquote><div>+1 !</div><div>It seems we can configure by repository and accomodate to several heterogeneous styles without massive reformat commit<br></div><div>(like ths 8-space tab stops, 2-space indent used in platforms/win32)</div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>frank </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div></div><div>Another thing to think about is the Language Server Protocol (<a href="https://langserver.org/" target="_blank">https://langserver.org/</a>, <a href="https://microsoft.github.io/language-server-protocol/specification" target="_blank">https://microsoft.github.io/language-server-protocol/specification</a>) 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, ...</div><div><br></div><div>frank<br></div></div></div></div></div></blockquote></div></div>
</blockquote></div></div>