130
Sounds nice, but I would prefer to have people responsible for committing code changes, not bots.
Besides, you want to make absolutely sure that those changes do not break anything. For example, we have a rule that orders properties and methods alphabetically. This can have an impact on functionality, for example with the order of data and methods in WSDL ...
73
In a statically typed language, Javadoc-style documentation is not for the authors, it's for the consumers. Autogeneration simply makes it easier for the authors to maintain the documentation for other people to consume.
If you're using a statically typed language and are not writing a library for third party consumption, autogeneration doesn't buy you ...
72
I would instead try to make it really easy for everyone in the team to apply automatic code formatting according to your team's standard directly inside your editor or IDE, to the current source code file (or selected parts of it). This gives your team members more control about how and when the formatting takes place, let them inspect the code before it is ...
37
It's a bad idea, not just because it discourages people from writing decent code, but also because the reformatting will show up as code changes in your VCS (you do use one I hope), masking the historical flow of the code's development.
Even worse, every code formatting action (indeed every change to the code at all) has the possibility to introduce bugs, ...
29
Having just started trying automated tests in our team, the biggest disadvantage I've seen is that it's very difficult to apply to legacy code that wasn't designed with automated testing in mind. It would undoubtedly improve our code in the long term, but the level of refactoring needed for automated testing while retaining our sanity is a very high barrier ...
28
I would tend to believe it is a good idea (to automatically run code formatters), but that is just my opinion.
I won't run them periodically, but if possible before version control commits.
With git, a pre-commit hook doing that would be useful. In many C or C++ projects built with some Makefile, I am adding some indent target (which run suitably code ...
answered Apr 12 '17 at 6:30
Basile Starynkevitch
28.5k5 gold badges67 silver badges105 bronze badges
26
You pretty much nailed the most important ones. I have a few minor additions, plus the disadvantage of tests actually succeeding - when you don't really want them to (see below).
Development time: With test-driven development this is already calculated in for unit tests, but you still need integration and system tests, which may need automation code as well....
26
Is there any logical reason to auto-generate code documentation?
From whose perspective?
If I were running the company or the dev group, then there's no good reason. I am staunchly in the "comments should explain why" camp. Forcing people to comment classes/functions/properties is worse than worthless, since they get out of date, they mislead the reader, ...
21
Perhaps the most important disadvantage is ... tests are production code. Every test you write adds code to your codebase that needs to be maintained and supported. Failing to do so leads to tests you don't believe the results of, so you have no other choice. Don't get me wrong - I'm a big advocate of automated testing. But everything has a cost, and ...
21
An automated build is a description of a process that should cover the following basics:
Fetch the latest code from Source Control
Compile the latest code into the executable
Run tests (unit tests, system tests, integration tests) against compiled code
Deploy completed executable to a known location for deployment.
Publish the results of the build.
5.1 ...
21
EDIT: I misunderstood the original question; although I think generating documentation (i.e. non-code documents) can be extremely valuable (see original answer regarding Doxygen below), auto-generating comments (which is something that GhostDoc actually does) sounds insane to me. I cannot understand why anyone would expect a program to be able to read un-...
17
In general, I think it is a bad idea. In principle it's a valid idea, but it can be problematic in reality. Having the code formatter break your code is a real possibility, and it only takes one formatting run to have your developers respond with (probably justified) hostility (e.g. "Your lousy code formatter broke the build, turn it off now!").
In the same ...
17
I think it's a bad idea. Many of the answers already covered that it dirties the history by making it difficult to pin down who actually added a line and that it encourages people to just commit whatever and the format-bot will handle it.
A better approach would be to incorporate a format checker into your build tool. (In Java there is Checkstyle) Then, ...
15
I wouldn't say these are entirely applicable disadvantages, but the few I hit most are:
Time taken to set up the test in a complex enterprise application.
Handling old tests that fail incorrectly, in other words, the system has evolved and now the tests are wrong.
False confidence from patchy or unknown test coverage.
Test coverage that is patchy can lead ...
15
Boss: AJ, We have 3 dogs, 2 rabbits, a catapult, and a nun. We need to find a way to get all 7 (yes, the catapult too) over a 20-foot wall and into the lake on the other side without the dogs eating any rabbits, and without drowning the nun. How long will it take you to come up with the solution?
See, the problem estimating how long it will take to solve a ...
14
You are correct in noting that, for some technologies, a compilation step is not necessary. However, I recommend you take a broader view when interpreting the term "build automation". Think about "build" as including the following two major components:
The process for transformation source artifacts (code, database schema, documentation, etc.) deployed to ...
14
While "development automation" is not a commonly used and recognized term of the software dev. industry, I have heard it many times in my life.
Business people normally use it to refer to "anything that can speed up the development process and allow the company to bypass most, if not all, of the software development process, jumping from a simple business-...
14
[...] document everything, and almost always with GhostDoc's auto-generated docs. Do you do this, and are there any rational reasons not to simply leave code undocumented if you aren't going to actually write the documentation yourself?
No. The documentation generated by GhostDoc is boilerplate (similar to how creating a new OO class in an IDE creates the ...
11
Powershell is not overkill. The point of Powershell is to bring powerful shell to Windows environments. It can be installed on XP and is included in later editions as default. It even has many linux commands implemented. If you work with Microsoft technologies(.NET, Sharepoint etc.), most of their products support powershell for automation and administration ...
11
I had to automate some little tasks at work, and found scripting under Windows (XP) with BAT scripts frustrating.
So the first thing I did was to install Python.
Scripting in Power Shell is not only for sysadmins, and I don't see it as overkill.
Another option you have is to use VBScript (or JScript for that matter). These are made for that exact purpose.
...
11
Important note
There is no out-of-the-box feature for this, and usually I try to steer people away from generic tasks like "Test", "Deploy" and have them think about testing all the way through the work and to have them define intermediate tests they want to execute along the way.
Generic stuff such a Release Notes and Deployment can be completely ...
10
Time for some serious "Continous Integration" for you.
These are the basic ingredients:
a source code repository (Subversion / Git / Mercurial)
an automated build tool (Cruisecontrol.net / Hudson or Jenkins)
a package-creator to create an installation-package (I recommend Advanced Installer)
First you setup your repository. Put all the source files of the ...
10
Your friends are being lazy and IMO unprofessional - the world will soon pass them by.
Daily builds were meant for projects following Agile practices. It
does not work for the waterfall model.
I don't have a definitive reference handy, but daily builds were common at least as far back in the 90's, so they pre-date Agile, and the *Unified Process ...
10
The task as stated is impossible. You might be able to come acceptably close depending upon your ability to compel evidence (ssn, drivers license, birthdate, etc). But unless you're a govermental site, most people will just go elsewhere.
10
Method to test
The method takes several arguments and returns a value, without using global state nor calling other parts of the application. It does one and one only thing.
This is a good start.
If the method was using global variables, testing could be difficult.
If the method was using other parts of the application, you could be forced to use mocks or ...
10
Yes, I think it's a bad idea. Don't get me wrong, the reason to do it sounds great, but the result could still be horrible.
You will have merge conflicts when pulling a tracked branch, atleast I fear that would be the case, I might be wrong though.
I don't want to test it right now at work, but you should try it out yourself.
In fact you can just check ...
9
I'd say the main problem with them is that they can provide a false sense of security. Just because you have unit tests it doesn't mean they're actually doing anything and that includes properly testing the requirements.
In addition automated tests can also include bugs themselves, so that brings the question over whether unit tests need testing themselves ...
9
From your comments I see you have a client/server database available, and you uploader already has a connection and write access? Then it would probably be easiest to add a "monitoring" or "status" table to the database and let your uploader report its progress there (log each "interesting" step there, probably the 5 steps you listed above).
To view the ...
8
I think you hit the nail on the head with the advantages you listed. Powershell gives you mobility and lets you move from source control to source control, but more importantantly lets you move from build server to build server, like Jetbrains' TeamCity. Since the scripts are independent and can be run from the command line, you can fire them off from ...
Only top voted, non community-wiki answers of a minimum length are eligible
