Closed akien-mga closed 7 years ago
-∞
NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO!
Please, no!
This is already a disastrous "feature" in a language where the correctness of a program depends on invisible characters. Please don't make the situation worse by encouraging different invisible character conventions.
And here's Ken Thompson's answer on the issue: https://www.youtube.com/watch?v=sln-gJaURzk#t=1735
This is a question out of curiosity that I've wondered for a while. What advantage is there to using spaces in your code instead of tabs? I've honestly never asked anyone and can't think of a reason myself.
Here are some benefits of tabs over spaces that I can think of (for IDEs and text editors in general): 1) Any programmer can change the spacing of all tabs accross an entire project with one setting without affecting the actual data. 2) There's less data, meaning one tab as opposed to 4 or 5 spaces. 3) If there's tabs only policy (especially in Python-like languages) all of the code is consistent regardless of who's working on it.
Again, I'm just curious as to what benefit spaces as opposed to tabs gives, thanks! :)
Well I did not want to start a flame war on tabs vs spaces, it's just a matter of personal taste that makes that I've taken the habit to use 4-spaces instead of tabs. So I like my IDE to let me configure the effect of pressing the "TAB" key.
I found this article which describes in a simple way why I prefer to use spaces. I didn't write it though, so if you find the argument irrelevant, please comment on the article and not here ;-) http://jarrodoverson.com/blog/spaces-vs-tabs/
For pure code-writing, I don't want to argue and I can see why tabs are preferred over spaces. But I'm used to RPM packaging and when editing spec files with nano (please don't bother telling me that I should be using vim, this is not the topic), I find tabs really uncomfortable. Here's an example of how it looks like:
%define luaver 5.1
%define lualibdir %{_libdir}/lua/%{luaver}
%define luapkgdir %{_datadir}/lua/%{luaver}
%define oname luafilesystem
%define realver 1_6_2
Name: lua-filesystem
Version: %(echo %{realver} | tr '_' '.')
Release: %mkrel 3
Summary: FileSystem library for the Lua programming language
Group: Development/Other
License: MIT
URL: http://keplerproject.github.io/luafilesystem
Source0: https://github.com/keplerproject/luafilesystem/archive/v%{realver}.tar.gz
BuildRequires: lua5.1-devel
Requires: lua5.1
So I've taken the habit to use spaces for alignment instead of tabs. And then this habit extended to code indentation, because I don't like to mix tabs and spaces.
And again, I'm just asking if a configurable indentation-style could be considered, I don't ask to change the default behaviour which is quite good IMO.
The compiler already throws an error if you combine spaces and tabs for indentation in the same file, so there's no danger of cf creating confusion by mixing invisible characters (we hate this too of python). Also, nothing stops you from using 4 spaces instead of tabs. What is the difference exactly between a 4 spaced tab and 4 spaces?
On Sat, Feb 7, 2015 at 6:54 PM, Akien notifications@github.com wrote:
For pure code-writing, I don't want to argue and I can see why tabs are preferred over spaces. But I'm used to RPM packaging and when editing spec files with nano (please don't bother telling me that I should be using vim, this is not the topic), I find tabs really uncomfortable. Here's an example of how it looks like:
%define luaver 5.1 %define lualibdir %{_libdir}/lua/%{luaver} %define luapkgdir %{_datadir}/lua/%{luaver} %define oname luafilesystem
%define realver 1_6_2
Name: lua-filesystem Version: %(echo %{realver} | tr '_' '.') Release: %mkrel 3 Summary: FileSystem library for the Lua programming language Group: Development/Other License: MIT URL: http://keplerproject.github.io/luafilesystem Source0 http://keplerproject.github.io/luafilesystemSource0: https://github.com/keplerproject/luafilesystem/archive/v%{realver}.tar.gz BuildRequires: lua5.1-devel Requires: lua5.1
So I've taken the habit to use spaces for alignment instead of tabs. And then this habit extended to code indentation, because I don't like to mix tabs and spaces.
— Reply to this email directly or view it on GitHub https://github.com/okamstudio/godot/issues/1340#issuecomment-73374812.
He wants the Tab key to insert X number of spaces instead of a tab. Which, whatever. I don't understand the need to use 4 or 8 of something when 1 will do. But, to each his own.
i honestly would rather not support this option, as it's terrible for teamwork, but i think being able to configure how many spaces the tab displays makes sense
On Mon, Feb 9, 2015 at 1:07 PM, adolson notifications@github.com wrote:
He wants the Tab key to insert X number of spaces instead of a tab. Which, whatever. I don't understand the need to use 4 or 8 of something when 1 will do. But, to each his own.
— Reply to this email directly or view it on GitHub https://github.com/okamstudio/godot/issues/1340#issuecomment-73535102.
He wants the Tab key to insert X number of spaces instead of a tab. Which, whatever. I don't understand the need to use 4 or 8 of something when 1 will do. But, to each his own.
See my above comments, the point is mainly that there are two use cases for the Tab key: indentation and alignment. Indentation using tabs is perfectly fine, but I don't like it for alignment purposes (e.g. aligned in-line comments or parameter definitions, the link I gave above showcases it well). And since I have to use spaces for alignment because I think tabs are not fitting, I prefer to use spaces everywhere.
But I see that I'm the only one finding that this would be a useful feature, so I guess the issue can be closed as WONTFIX :)
If this feature isn't added and you're mostly worried about comment alignment you may consider putting your comment on the line above. This is what I usually do anyway when I do comment. Although the truth is that I usually just write my code in a way that it doesn't need to be commented. For instance, naming variables and functions descriptively.
Kind of a loose example would be if I wrote a Random function where you can get a value back within a range:
Note that I'm using // instead of a hash because it messes with the markdown.
This is kind of messy in my opinion:
func RandomRange(a, b): // a = minimum value, b = maximum value
or you can comment like this:
// a = minimum value, b = maximum value func RandomRange(a, b):
or what I prefer is to make my code descriptive in a way that it doesn't need a comment. It's not a hard rule that I follow, there are obvious places that need commenting such as a complex algorithm:
func RandomRange(minimumValue, maximumValue):
I literally almost never write comments anymore unless for the sake of using programs like doxygen. I try not to let it get ridiculous by making names too long, but if it means only adding a few extra characters to my function or variable names, so be it. It's better than reading extra documentation.
Funny that the Python PEP-8 style guide strongly encourages spaces then (it is written by the author of Python, who now admits that allowing either spaces or tabs was a big design mistake).
Space indentation makes a huge difference if you follow a maximum line width idea, since indenting follow-on lines consistently is very messy with mixed tabs and spaces. If you don't do this and just have lines as wide as needed, then there is a lot less reason for not using hard tabs and I can see why it would seem non-nonsensical to consider pure-spaces.
As above, I suggest that the option to use either is necessary. In fact, I believe that using spaces exclusively would be a lot easier for new users, since they'd never get confused by mixing white-space characters, but I'm more than happy for the tab system to stay as the default.
i honestly would rather not support this option, as it's terrible for teamwork
I think it's exactly the opposite; other people on your team may use external editors configured for spaces rather than tabs -- hell, they may have already established coding conventions that require them. With the godot editor non-configurable it's impossible for you to collaborate with them without breaking the rules.
Not to start a holy war, but my 2c...
[..] In fact, I believe that using spaces exclusively would be a lot easier for new users, since they'd never get confused by mixing white-space characters, but I'm more than happy for the tab system to stay as the default. (@Spooner)
On the contrary, try using Code::Blocks with the default space-based indentation for a while, and see how terrible those things can be. At least with older version, after about 30 minutes, the editor would have already managed to make it 7 instead of 8 spaces on some lines, and since it would copy the indent from the previous line, this would soon plague the whole codebase. Same would happen with any other editor -- no matter how good you made the hack to use more than one character instead of just one, some keybinding/shortcut/etc. would delete or insert only one of the characters, and break the whole thing. Also, consider that "show invisibles" is on, and someone types 9 spaces instead of 8 -- would he be even able to detect them?
Anyway, "more options is more options", thus feel free to make a PR, that would add this to the project settings (with a default in the editor settings probably, but better not) :wink:
I'd rather that the editor be enhanced in such a way that it disallows any whitespace at the start of a line other than tabs.
I wouldn't add such setting unless we have an option to automatically convert all the file indentations to the current mode.
+1 this feature! I really want this option in the Godot script editor. This is a basic feature that any advanced text editor has. The best-in-class Python editor, PyCharm, can also do this.
I think a few of the other comments aren't fully understanding what is being requested here. Just in case anyone was thinking otherwise, this isn't asking for any default behavior to change whatsoever. Merely that there is an option that can be enabled so that when you press the tab key, a configurable number of spaces is generated rather than a tab character.
+1
I too would like to see the option to have TAB insert spaces. This is how I have Geany, my fave python IDE, configured.
The main reason I see for this (to use spaces instead of tabs) with Python-esque languages like gdscript is that people can have TAB set to an arbitrary number of spaces hence if anyone working on a team project isn't using the same TAB settings, havoc ensues due to the indentation-dependant nature of gdscript and python. You don't have this prob if you stick to spaces and space tabs.
Making this setting project dependent and making editor mark all non-compliant files will make this feature useful IMO. This can be complemented with a feature to change all non-compliant files to comply with project indentation settings. Also track of exceptions to automatic conversion must be kept like borrowed codes from projects with different indentation settings which may be updated by git sub modules like work flow I think.
Besides, I prefer tabs while writing PHP and spaces (4 not 2) while writing Python. But Godot using tabs for indentation is a dream come true for me. Which separates code from indentation clearly in my opinion and also make navigation by arrows easier.
When I navigate space indented code vertically I feel my self like a racing car in quicksand so I prefer tabs for indentation wherever possible.
We don't need to discuss further whether tabs or spaces are better for indentation. It has and will always be a controversial topic, we won't find the answer here.
What is clear already is that there would be interest from many users to have a setting to default to space indentation.
It just needs someone to implement it as a setting (trivial) and to make sure that autoindent works with the configured character(s), which is non trivial (tab is hardcoded in various places). Hopefully the GDScript parser should already support space indentation, so it's only an editor usability feature.
I'm doing a few tutorials, and the code snipets in them use 4 space identation. Yet, there is a print screen showing the visible tabs in the editor.
Maybe, instead of OPs proposal, the editor could fix the indent style when pasting. And/or provide a tool under Edit menu to convert space indents to tabs.
I am used to using 4 plain spaces instead of a tabulation character when writing code (especially Python, and GDScript is quite similar), but as far as I can tell the script editor enforces the use of 4-space-wide normal tabulations.
Would it be possible to add a setting to be able to chose between tabs and spaces for the code indentation?