Closed Sigmanificient closed 1 year ago
Moreover, my code editor is going absolutely crazy, with pretty much every line being underlined.
What editor do you use? could you send a screenshot?
The formatting is pretty unusual
It is indeed, but I'm strict with the formating of the code. I prefer to utilize the vertical blank spaces and such the code to look like blocks of columns:
It would be nice to provide a configuration for your code styling via pylint to a similar tooling,
I don't really know\understand how to provide a configuration of the code styling, I just use Neovim :P
or maybe use a more broad formatting like black (mostly based on python pep8) or flake.
feel free to express your coding style just as you like (but just don't change everything to your style)
I use PyCharm as my editor of choice for python codebases.
It seems like PyCharm needs to adapt to my coding style hahahaha... Ohh god how many warnings! there should definantly be a config file where you can disable identation stuff like this
VSCode and NVIM, don't have those issues
It seems like PyCharm needs to adapt to my coding style hahahaha...
PyCharm uses a pylintrc as a reference. If such configuration isn't provided, i will automatically use the default standard formatting (aka pep8)
VSCode and NVIM, don't have those issues
Well they are meant to be modular code editor unlike PyCharm which is by default a full-fledged IDE.
If you install plugins to enhance your VSCode / NVIM experience, it is likely that you will come across the same issue as most plugins for coding style checking will be based upon the pep8
styling.
You can disable checkings, at least in NVIM and VSCode. There should be something simmilar in Pycharm too i guess
Anyways do whatever you feel like, just don't reform existing things to pep8
You can disable checkings, at least in NVIM and VSCode. There should be something simmilar in Pycharm too i guess
Well indeed, but providing a pylintrc
would be a better way to handle this issue
I've no any pylintrc
, iI just use a custom setup with LSP and stuff
Well you should then start looking into it, as other python purist will surely start complaining about the code formatting at some point, especially if you don't provide any way to get aligned with your specific format.
Btw I dont think that putting one-line conditional body in-line with the header is a good practice.
Take for instance this following code:
def paste(self): # TODO: ask to check if overwrite on copy
"""
Pastes the already selected and copied/cutted files.
"""
if len(self.__temp__copied_files) == 0 or not os.path.exists(self.__temp_dir_of_copied_files): return # u never no if the user deleted anything from other file manager this is also something i haven't consider for the rest of the things and [...]
if self.__temp_dir_of_copied_files != self.directory: self.__copy_cut ()
else : self.__duplicate()
self.reload()
The conditional body is pushed to the right, leading to longer lines that are harder to read. This is especially true when comment are suffixed. It cause a lot of uneeded wrapping (line going back to a newline) that makes the code more complex to read.
For git, code review often cause overflow, and the diff lead to less information as both conditional header & body are cluttered together.
# TODO: ask to check if overwrite on copy
def paste(self):
"""Pastes the already selected and copied/cutted files."""
if len(self.__temp__copied_files) == 0 or not os.path.exists(self.__temp_dir_of_copied_files):
# u never no if the user deleted anything from other file manager
# this is also something i haven't consider for the rest of the things and [...]
return
if self.__temp_dir_of_copied_files != self.directory:
self.__copy_cut()
else:
self.__duplicate()
self.reload()
On the second code block, it is way easier to see that the first condition is a guard block and the second one is a more important action block. The conditions themselves are separated with spaces, which makes the whole function feel less cluttered and different actions have a better separation.
This is indeed an edgy senario even for me, but I still when i look at it, i look at it as a work of ascii art ngl tbh xD
That else
statement_____ went farther than my feature as a human being hahahaha
I noticed during my small dig into the source that the formatting is pretty unusual, making it hard to understand a lot of what is happening and how to structure the code i want to add. Moreover, my code editor is going absolutely crazy, with pretty much every line being underlined.
It would be nice to provide a configuration for your code styling via pylint to a similar tooling, or maybe use a more broad formatting like black (mostly based on python pep8) or flake. The second option would allow to use contigeous integration to insure future code to be well formatted and would keep it under close standard to python developers.
What are your thoughts about it?