DEV Community

Tamir Bahar
Tamir Bahar

Posted on

IDE-isms - How does your IDE affect your coding style?

IDEs are really nice tools. With refactoring, auto-completion, and various types of analysis. But they are not perfect. To circumvent IDE bugs, I often alter my coding style to match the IDE and avoid false-warnings.

Do you have any such IDE-specific coding styles?

Latest comments (11)

Collapse
 
vasilvestre profile image
Valentin Silvestre

I'm coding in PHP and PHPStorm + plugins (PHP EA inspections & more) are changing my way to code.

It force me to apply best practice, the code sniffer tell me that I'm not PSR compliant (standards recommandations).

It make me a better developer :)

Collapse
 
djtai profile image
David Taitingfong

If the IDE has some linting capability, then I pay more attention to things like extra whitespace. Otherwise I style my code the same across any IDE - or anywhere else I write code for that matter.

Collapse
 
johnpaulada profile image
John Paul Ada

Nah. I use VS Code or Vim sometimes. In Java I use Eclipse but that doesn't really affect me too much.
I think linting changes my coding styles but they're not really IDE-specific.

Collapse
 
danieljsummers profile image
Daniel J. Summers

I'm so crusty at this point that I get frustrated with the IDE if it doesn't conform to my style. :)

/grumpy-old-man-reply

VS Code's ability to pull in types on JavaScript if you declare them in JSDoc encourages me to make sure I comment my exported values completely.

Collapse
 
tstephansen profile image
Tim Stephansen

When writing in Visual Studio my curly brackets for methods are on a new line but when I use any of the Jetbrains editors I leave the first on on the same line.

Collapse
 
danielfavand profile image
Daniel Favand

For myself I don't know if it's the IDE itself (VS Code) but actually taking the time to set up linting plugins (actually just eslint) has definitely changed (standardized, if not improved) my style. I need to find a good guide to programming js with VS Code because I'd like to take advantage of feaures like intellisense for my modules and automagical beautification.

Collapse
 
tmr232 profile image
Tamir Bahar

I think auto-completion (with Intellisense or the likes of it) has changed the way I name & scope things. Namespaces (or modules, or whatever your language supports) are a nice way to filter out completions quickly. Prefixes are useful as well.

Collapse
 
maxart2501 profile image
Massimo Artizzu

Huh, never thought about it. But I guess it makes sense. I don't use IDEs, but one of the many supercharged text editors that and trending lately (like Sublime, Atom or VS Code).

I used to write very messy code once. Now I think I've improved a lot, but I don't know if it's more because of the editor, or just because of necessity :)

The best thing that helped me improve my code style is the multi-cursor. The second best is a hotkey to expand the current selection to the next occurence (usually Ctrl/Cmd+D).

Recently I've switched to VS Code like a lot of developers, and even though I thought I could do without Intellisense, it's a very nice thing to have. I'm not sure if that influenced my code style, but surely it's changed how I write code.

Collapse
 
tmr232 profile image
Tamir Bahar

Thinking about it, IDEs have had a tremendous effect on the way I code.
In Python, I used to write a lot of scripts, then throw them away, then write them again. Using PyCharm, I was forced to create "projects". At first, this was annoying. So I created one main project where I host all my shitty scripts. Over time, it became a really nice library :)

Collapse
 
ben profile image
Ben Halpern

I have to think IDE's had a lot to do with the insanely long names used in objective-C. I'm not super aware of Apple's history before xcode, but I would imagine auto-complete would have a lot to do with this convention.

Collapse
 
tmr232 profile image
Tamir Bahar

I noticed that when writing C++ is CLion, I tend to initialize member reference variables with () instead of {}.

// CLion < 2017.3
struct Foo {
    Foo(Bar& bar): _bar(bar) {
    }

    Bar& _bar;
}

// CLion >= 2017.3
struct Foo {
    Foo(Bar& bar): _bar{bar} {
    }

    Bar& _bar;
}

This was because CLion had an some issues with initialization lists, and kept warning me that the latter is wrong. Now that the bug is fixed, my code style is changing.