zlacker

[return to "Screenshots from developers: 2002 vs. 2015"]
1. henghe+D3[view] [source] 2015-12-12 14:04:39
>>quanti+(OP)
I don't do a whole lot of software (got caught up on the hardware side of things), but one thing I'm noticing is that nobody makes extensive use of "advanced" IDE features as in eclipse or visual Studio.

Is this personal taste, or has it to do with the scope of the projects these guys are working on?

◧◩
2. JustSo+M6[view] [source] 2015-12-12 15:08:57
>>henghe+D3
For me, IDEs are great for when I have to do boilerplate coding. But when I switch to real business logic I use an editor like vi or sublime. Anything more impedes my thinking and gets in my way.
◧◩◪
3. edwinn+37[view] [source] 2015-12-12 15:15:58
>>JustSo+M6
I'm guessing you're probably not writing unit test or use code coverage plugins or running static code analysis to provide feedback incrementally and quickly?
◧◩◪◨
4. aarone+a9[view] [source] 2015-12-12 15:57:42
>>edwinn+37
What has any of those things to do with someone's choice of editor?
◧◩◪◨⬒
5. edwinn+wd[view] [source] 2015-12-12 17:17:28
>>aarone+a9
I take it you've never used those IDE with the plugins to support the workflow I mentioned above...
◧◩◪◨⬒⬓
6. aarone+ne[view] [source] 2015-12-12 17:37:20
>>edwinn+wd
Well, it depends on what you mean, I suppose. I've integrated Emacs with tools like those, so that I can (for example) get linting feedback on code in real time, or jump to locations from a unit test failure report. But I've never written unit tests, or used coverage or static analysis tools, that depended on Emacs, or indeed on any other editor. I've never even seen that kind of tight coupling, much less perpetrated it myself. I'm not sure whether that's what you're talking about, or whether it only sounds like that's what you're talking about, but I hope it's the latter.
◧◩◪◨⬒⬓⬔
7. edwinn+uL[view] [source] 2015-12-13 05:07:05
>>aarone+ne
There are 2 workflows here:

1. the ability to run everything (a.k.a the whole project) using the preferred SCM (or build tools)

for example: mvn clean install

where your pom.xml already set to have cobertura (code coverage), checkstyle/pmd (linting/style/formatting), and findbugs (static code analysis)

2. the ability to run a very specific unit-test somewhere deep down in your project via your IDE as you're writing code (the IDE compiles your code on the fly...) and get everything I mentioned above :)

for example: I want to run one new unit-test for a new code => I don't have to drop to my console/command-line/terminal to run mvn clean install. I just go to my unit-test, highlight the method name, run it through eclipse/intellij and I get everything.

◧◩◪◨⬒⬓⬔⧯
8. aarone+M31[view] [source] 2015-12-13 15:53:20
>>edwinn+uL
Oh, is that all? There's nothing special about that. Any decently capable editor should be able to do likewise. I don't know about Vim because I don't use it, but I would assume it can, and I know very well that Emacs can because I do such things in Emacs every time I write code.

Of course it doesn't work exactly the same way; for example, running a single test doesn't involve highlighting it and telling Emacs to do something magical, but rather flagging it in a way that's specific to the test runner and then doing M-x compile RET RET to point the test runner at that file. The first time I do that, I have to tell Emacs what command I want it to run, but that's no great hardship, since it's buffer-local (each file I'm editing has its own value) and, being a simple test harness invocation, need change only when the filename does. If it matters to me, I can put this information in a configuration file, so I don't have to worry about typing it out even the first time. So far, it hasn't mattered to me. (And, yes, when I run a single test this way, I still get coverage information. Linting happens inline, as linting should, so doesn't really figure into things here.)

The mechanism differs somewhat from what you describe, but the result is the same. Just highlighting the desired test and invoking a keybinding might be a little quicker and more convenient, but so far it hasn't seemed enough so for me to go to the effort of writing Lisp code to do it. It wouldn't be much effort, but since invoking a specific unit test alone takes about a second, it also wouldn't save me much time, which is why I haven't bothered doing it.

A major point of interest here is that none of this workflow is specific to a single language or a single toolset. It works the same way across all the languages I use. Since I work in multiple languages on a daily basis, that's very important to me. It sounds like you work primarily, perhaps exclusively, in Java, so that's not as important to you. The problem is, you seem to have assumed that nobody else's tools can do the same awesome things your tools can do. As I hope you've gleaned from this comment thread, that is rather untrue, and proceeding from the assumption that it is makes you come off as both ignorant and arrogant. What you do with this information is, of course, entirely up to you.

[go to top]