sqlfluff VS ale

This linter can really enforce some best practices https://github.com/sqlfluff/sqlfluff

A list of best practices:

BigQuery SQL and SQLFluff

There's a SQL parser/linter called SQLFluff that my team uses for our CI/CD. I've made a few pull requests to fix the parser for the particular SQL dialect we used, and my college compiler classes definitely helped.

Include bells and whistles to impress the reader: Most projects will have the common things like ETL scripts (e.g. SQL, Python, Airflow, dbt, etc) covered. To go the extra mile and stand out, you should also include things like data quality tests (e.g. dbt tests, great expectations, soda), linting scripts (e.g. sqlfluff, black), CI pipelines that check for linting and unit tests for ETL code before code can be merged to main (e.g. github actions). Include instructions on how to run those tests or linting or CI pipelines in your README file and include screenshots of the success or failure output to give the reader an example.

Capitals I pretty much auto write, although I'll used the code formatter I wrote if someone sends me something messy. Bad and reused aliases, however, require manual fixing before I can get to the code review stage, so a PR using those will be rejected as needs work. sqlfluff is a decent formatter & linter if you need to get into details like that regularly.

SQLFluff

Not serving all of our needs but it did its job: https://github.com/sqlfluff/sqlfluff

sqlfluff – A SQL linter and auto-formatter for Humans

Disclaimer: Be mindful that the results may be unpredictable and the code generated should be carefully evaluated for correctness before use in production systems! Use a linting tool such as ALE to check your code for correctness.

If you are interested in alternatives the ALE plugin https://github.com/dense-analysis/ale can automatically detect if tools like shellcheck are installed and will just magically lint your files continuously in the background with nice highlighting. Worth a look!

Hello everyone! I just now finished setting up a pretty ambitious ALE 4.0.0 milestone, and I want to get most of the work done by Christmas. I cannot do it alone, so I'm posting an open call to contributors to help Dense Analysis with it. You can see the milestone here: https://github.com/dense-analysis/ale/milestone/10

As of a couple of days ago, and through the work of mostly people who aren't me, ALE now supports displaying problems via Neovim's diagnostics API. You can see the commit here.

https://github.com/dense-analysis/ale/blob/master/supported-tools.md ALE has been around for over 6 years and supports a gigantic list of tools out of the box, and not just through LSP. It has the weight of a nonprofit organisation behind it and a large community of maintainers.

I am the person who created the initial request 4005 back in Dec 2021. So quite the journey to get here.

https://github.com/dense-analysis/ale/issues/4208 I suspect this issue I have pinned is most likely related.

``` call plug#begin() Plug 'https://github.com/dense-analysis/ale' Plug 'https://github.com/phanviet/vim-monokai-pro' call plug#end()

To replace coc and ale, you'll probably need to install more than two plugins. Neovim is in fact well known for its built-in LSP, which can be configured in many ways. The quickest one is by using lsp-zero, which sets up automatically language servers and autocompletion, without you having to write everything on your own. Alternatively, you can manually set up mason, nvim-cmp, null-ls and more, to achieve a similar result with your own efforts. I will write another blog post about this, so stay tuned.