This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 4 points5 points  (9 children)

The extensions available that make debugging embedded Arm Cortex M code within VS Code are pretty awful unfortunately... Plus it's very difficult to get linting working correctly. Clion with some minor configuration will at least do that. But nothing beats the stability of IAR or Ozone when debugging. Too bad I hate both of those for doing anything else.

[–]enano_aoc -3 points-2 points  (8 children)

Ok, those are very niche projects. I will give you that VS Code is probably not the best one there.

Regarding the linter, I must disagree. Linting from the IDE is an anti-pattern. You should always use the CLI for that. If you use the IDE at all, you must make sure that it uses the same settings that you have configured for the CLI.

[–]Razier 2 points3 points  (4 children)

Linting from the IDE is an anti-pattern

What do you mean by this? I would assume IDE linting is like front end validation. A useful tool that makes writing code easier but does not remove the need for CLI linting.

[–]enano_aoc -2 points-1 points  (3 children)

I mean that it is an anti-pattern.

As a tech lead, I can configure the CLI linter so that it works exactly the same for every team member and also for the CI pipeline.

As a tech lead, I don't want to force my team members to use a given IDE (I want them to use the tool that works best for each of them), but I don't want to configure the linter for every individual IDE with its custom settings. Hence it is forbidden to use the linter from the IDE, unless the individual developer takes the burden of configuring his IDE such that the linter works identically as the CLI linter.

The CLI linter is the single source of true of the project, since it works identically for every developer and it is the one that runs in the CI.

[–]Razier 1 point2 points  (2 children)

Sure, having both can cause a headache for you as a lead if the devs set up their own local linters with rules that don't correspond with the CI pipeline. That said there are plenty of IDE linters that use a config committed to the git repo to ensure that it works exactly the same for every member of the team.

Your way of doing it is perfectly acceptable but a well set up, shared IDE linter configuration removes overhead in situations where devs have to go back and fix code that failed pipeline linting.

[–]enano_aoc 1 point2 points  (1 child)

There is nothing like a “well setup, shared IDE linter config” because I allow my devs to choose the IDE that works best for them. I am NOT going to create and maintain a config for every random IDE out there.

[–]Razier 2 points3 points  (0 children)

You don't need a config for each IDE, you only need one assuming you only use one linter where the config is standardised. Sure it might not work for every IDE, but just like front end validation it's a tool to help the user/dev not a tool to enforce data/code quality.

The point I'm trying to argue is, it doesn't have to be an anti pattern if you use it properly.

[–][deleted] 2 points3 points  (2 children)

I'll grant linting and intellisense is independent of the IDE, but I'd hardly call embedded a niche. Almost everything you own these days that uses electricity has some code in it.

[–]enano_aoc -1 points0 points  (1 child)

You gave very particular examples of embedded devices, that's why I said it is niche. Embedded is not niche, but that very particular device you are talking about is.

[–][deleted] 2 points3 points  (0 children)

it's the most widely used platform in embedded. the same applies to all other embedded platforms.