MNT: Refactors the code to adopt pylint

[Gui-FernandesBR]

We are going to officially adopt pylint in this repo.

Github Actions workflows erre updated:

• The black/linter bot will no longer commit to this repo
• When opening a PR, isort, black and pylint will be executed to verify if the code follows

I fixed many pylint errors, but it was a really hard task, quite time consuming. Therefore, I had to use pylint-silent to ignore some errors, those will be solved in the future, one by one.

You don't have to read all the files. Focus on the new github workflow files and the .pylintrc file

[phmbressan]

Good work. I left some suggestions, I am not an expert on linters, so take those with a grain of salt: but I do think some of the defined linting rules are not strict enough.

This already has produced improvements and more idiomatic code and has potential to accelerate our reviews.

For the long term, let's keep in mind always that linters are good to suggest improvements, but they do not force you to anything, there are edge cases.

[Gui-FernandesBR]

We should add a fallback linter: another linter that is run after pylint to capture eventual errors not captured by the main linter.

I would say that ruff, the "yougest and fastest" player in the market right now, is our best candidate. I will let it for the next PR.

Flake8 would be the more "natural" option.

Maybe we could run flake8 AND also ruff.

---

@phmbressan I have fixed your comments. Please take in mind that I didnt't care too much about the errors threshold at this first time. I was more worried about getting everything to run.

[codecov]

Codecov Report

Attention: Patch coverage is 78.69249% with 88 lines in your changes missing coverage. Please review.

Please upload report for BASE (develop@23fa110). Learn more about missing BASE report.

Files	Patch %	Lines
rocketpy/environment/environment_analysis.py	18.18%	27 Missing ⚠️
rocketpy/simulation/flight.py	58.69%	19 Missing ⚠️
rocketpy/motors/solid_motor.py	50.00%	7 Missing ⚠️
rocketpy/prints/aero_surface_prints.py	77.77%	4 Missing ⚠️
rocketpy/tools.py	42.85%	4 Missing ⚠️
rocketpy/utilities.py	75.00%	4 Missing ⚠️
rocketpy/environment/environment.py	86.95%	3 Missing ⚠️
rocketpy/plots/compare/compare.py	40.00%	3 Missing ⚠️
rocketpy/plots/rocket_plots.py	50.00%	3 Missing ⚠️
rocketpy/plots/environment_analysis_plots.py	86.66%	2 Missing ⚠️
... and 10 more

Additional details and impacted files

@@            Coverage Diff             @@
##             develop     #621   +/-   ##
==========================================
  Coverage           ?   73.91%           
==========================================
  Files              ?       70           
  Lines              ?    10032           
  Branches           ?        0           
==========================================
  Hits               ?     7415           
  Misses             ?     2617           
  Partials           ?        0           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[MateusStano]

FD was used here because it is the naming used in the formulas. This makes it easier to review/understand the following equation. I don't think we gain anything from having an extensive name here

[Gui-FernandesBR]

Speaking as someone that opens a PR every week but hasn't review any technical equation in the last few months.
I personally prefer the more readable way. I don't really know what FD means.
Making it explicit is better than implicitly.

But I understand this can be quite personal.

Still, I think you will agree with me that the fins' equations are a "hard-to-read" code block.

[Gui-FernandesBR]

I'm reading this again.
I honestly can't agree that self.AR is more readable and less error-prune than self.aspect_ratio

[Gui-FernandesBR]

A third opinion would be nice