This is a popular point of view in general (programming tools serve programmers) and the natural and most free spirit of free-form programming languages.
It turns out that there is a good argument--an evidence-based theory of software development--that you might want to think about as you form your opinion on the topic: a. Programmers spend more time looking at other people's code than creating their own. Naturally this is based on the kind of programmer. Single person building single-use programs (such as school assignments) would not have this character, but multiperson teams are like this and even single-person code looks foreign after a few years. b. Programmers spend more time studying API interface documentation than coding. Again, true at Goolge, IBM, SAP, etc., maybe not so much at home or school. c. Programmers spend much time debugging; this time is controlled by the presence of comprehensive large and small scale tests and the effort needed to operate and interpret them. Same idea of who the programmer is here as well...a professional person part of a team is the model. The data for a-c comes from universal experience in large teams and large companies. It is possible to design a programming language, documentation system, and test infrastructure to address these issues and make them easier, simpler, more uniform, and in the limit, to design/tool around the problem in the first place; that design is called Go. That's the good. The price you pay is that it casts Go as a Language WIth an Attitude (TM) (Rob Pike). That plays out as follows: A. Since you'll be looking at the code of others, the best thing for you is if the code all looks "your way" stylistically. Since you will be using GIT or some other SCM system, then the code that looks "your way" needs to be unchanging. The solution? Define a common way and tools for that. Go implements this. Looks like you did not win the lottery on this point--the common way is not your personal preference. Not mine either. There is good news though...it only takes a week or so before you don't even notice. The benefits hugely outweigh the cost so it is firmly seen as a win for Go by most everyone. B. The documentation is generated from the code (so comprehensive) and includes examples (formatted consistently as well.) C. The testing infrastructure is not "in" the language but is built as a peer of the language. It does not really implicate the formatting but it is at the same level of "do everything consistently" as the indentation and layout. The argument for consistency here is that secondary tools can read the output of the tests and build aggregate reports. Because of this, the formatting of the tests is also fixed so that the tools people build are not broken by subtle output formatting. This is much like the indentation argument, except that it serves programs rather than programmers. Hopefully you will give these ideas some thought. Maybe they will help you find peace with style choices that are not your favorite. On Thu, Mar 9, 2017 at 7:07 AM, <thecoffee...@gmail.com> wrote: > I see this as an opportunity for a smart ide dev to solve a problem. > > This argument/divide/preference should not exist. We're talking about > tokens that are interpreted by a machine - how those tokens are display on > screen in an editor should never have depended on the damn white space/tabs > etc saved in the text file. They're literally meaningless and should all be > standardised on file save. > > We could strip all meaningless white space characters on save but we > probably want to enforce a single standard to aid in unassisted reading of > the code in non-code aware editors. > > However, If an individual has a preference for formatting style then the > code editor should transparently transform their display of the code like > CSS transforms HTML. Then there's no need for this colossal thread - > individuals can have whatever style they want, the underlying source is the > same for everyone. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Michael T. Jones michael.jo...@gmail.com -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
