GiorgosXou / TUIFIManager

A cross-platform terminal-based termux-oriented file manager (and component), meant to be used with a Uni-Curses project or as is.
GNU General Public License v3.0
688 stars 13 forks source link

Code Formatting #42

Closed Sigmanificient closed 1 year ago

Sigmanificient commented 1 year ago

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?

GiorgosXou commented 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:

tuifiimage

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)

Sigmanificient commented 1 year ago

I use PyCharm as my editor of choice for python codebases.

image

GiorgosXou commented 1 year ago

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

GiorgosXou commented 1 year ago

VSCode and NVIM, don't have those issues

Sigmanificient commented 1 year ago

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)

Sigmanificient commented 1 year ago

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.

GiorgosXou commented 1 year ago

You can disable checkings, at least in NVIM and VSCode. There should be something simmilar in Pycharm too i guess

GiorgosXou commented 1 year ago

Anyways do whatever you feel like, just don't reform existing things to pep8

Sigmanificient commented 1 year ago

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

GiorgosXou commented 1 year ago

I've no any pylintrc, iI just use a custom setup with LSP and stuff

Sigmanificient commented 1 year ago

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.

Sigmanificient commented 1 year ago

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.

GiorgosXou commented 1 year ago

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

GiorgosXou commented 1 year ago

That else statement_____ went farther than my feature as a human being hahahaha