On Tuesday, 4 September 2018 at 22:38:08 UTC, Nick Sabalausky
(Abscissa) wrote:
On 09/04/2018 04:00 PM, Jonathan M Davis wrote:
On Tuesday, September 4, 2018 5:56:54 AM MDT ShadoLight via
Digitalmars-d
wrote:
We work full-time for employers which, in my case, employs
thousands of engineers - and as a result engineering
principles
are applied to everything - including tools. So all SW dev
teams
here use standardized tooling/processes/coding standards/etc.
-
you simply do not have a choice to use your own editor of
choice.
Honestly, I don't understand why it would make any sense to
require that all
of the programmers use a particular code editor. Standardizing
the build
tools makes perfect sense (in fact, it would be crazy not to),
and I've
certainly worked at places that have required that a specific
tool like
visual studio or eclipse be used, because it's used for
building, but
they've never then disallowed using a tool like vim or emacs
for code
editing. And if an employer did, I'd almost certainly be
looking for a new
job (though finding a job that sucks less than your current
one is
frequently far from easy).
Yes, exactly. Out of all the actual employment-based jobs I've
had writing code, not a single one would've cared what editor I
was using, as long as I was getting my work done and not
causing problems.
I in fact share your (and Jonathan's) view on this i.t.o.
editing. But it is not as simple as you make it sounds - the fly
in the ointment is often debugging, not coding.
For example, all devs in my team, besides participating in 1 or 2
projects's _development_ at any one time, you also have to do
support: most of this entails fixing some reported issue in
applications in production that you (often) did not write or even
contribute to (we have a lot of legacy projects still in
production - a few go as far back as VC++ 6 solutions!). Lets say
in a legacy VS2008 C++ solution (1xEXE project with many (often
10+) DLL projects). Often with these kind of projects the
EXE/DLL/LIB output is directed to a specific folder (with the
necessary INI/CFG files, test files, etc are all present) as well
as scripts to update registry, etc - i.e. to set up everything to
allow testing.
It is quite quick (and VS is normally very reliable with this) to
import the legacy VS2008 solution into VS2015 - rebuild the whole
thing, set some breakpoints and start debugging (and I echo
Manu's sentiments here - VS has the best integrated debugger in
the business bar none!). Find the bug. Fix the bug. Run unit/CI
tests. (All from within VS). Update release-note. Release new
updated version to Deployment. Check fixed sources into Version
control. Move on to next bug or back to normal dev...
Are you really telling me you are going to port each of these VS
Solutions with all the project details into the equivalent
Vim/Emacs structure just for each and every of the projects you
have to fix? Every time? The actual coding part (fixing the bug)
actually most of the time takes much less time than the rest of
this process.
Whether you believe your Vim/Emacs can be tuned with the
necessary plugins to achieve the same result is actually
irrelevant here - the question is can you fix each bug as quickly
as I can by just staying in the original VS ecosystem.
It is also not a question if your employer/organization allows
you to code in your editor of choice (we are allowed to do this
in fact - I frequently use (and love!) Notepad++, and I even have
VisualD installed at work to toy with D over lunch). The real
question is if your organization has/needs a standard for project
solutions under source control. So in our case, irrespective of
what you use to develop the project, under source control it has
to be a VS solution - because that is the standard dev tool in
the team.
It is simply not viable to imagine that everyone can check out
and convert each project solution (be it VS/eclipse/whatever)
into their own favorite editor equivalent (mostly through a host
of different plugins, with no standard way in sight!). And then
having to update the (lets imagine VS) solution under source
control with the Vim equivalent solution (for future Vim users),
just for the next guy to add the Sublime way.
As much as I too would have liked unfettered freedom to do things
"my way", I can fully appreciate why there needs to be a
"standard way" (at least in serious engineering organizations
where multiple developers can and do work on the same code bases).
Note that I do not think my organization "sucks" because of this
requirement and that this necessitates finding another job "if
you have an ounce of dev self respect" left! (I know, I
exaggerate a bit here, but you get the drift!). I think you
should consider yourself quite privileged if you can dictate the
choice of all the tools you use - this is obviously easier for
new projects or if you work alone on a project or other
developers will not need to access/change/fix your code base.
Also note that this is not much different to why, even for D,
there is still an insistence to follow D's coding standards for
contributors. Both are intended to simply make it easier for
multiple devs/contributors to code/fix/contribute. It is the same
principle.
