Here's a breakdown of the answer: one part focuses on determining the better choice between two options, while the other part emphasizes that neither option is ideal!

---

So, which option is correct?

It looks like this one:

$scope.addToDo = function(params1, ...) {
    alert(params1);
}

Why? First off, A - it's testable. Even if you're not specifically writing tests, having code that can be tested makes it more readable and maintainable in the long term.

Additionally, B - it's agnostic to the caller. This means it can easily be reused by various controllers or services without being tied to a specific scope structure.

If you go with this approach instead:

$scope.addToDo = function() {
    alert($scope.params1);
}

Both A and B fall short. It lacks ease of testability and reusability due to its dependence on the structure of the scope.

Edit: If your scenario involves closely tied logic to a specific scope and calling the function from the template, making it reusable might not be practical. In some cases, functions are just not generic enough for reuse. Keep the default mode but acknowledge when it may not apply.

---

Why are both approaches flawed?

As a general rule, logic shouldn't reside in controllers; that's where services come into play. Controllers should utilize services to handle logic or expose it in a model rather than defining it themselves.

The reason behind this principle? Once again, it promotes function reusability. Functions defined in controllers limit their use across different controller contexts embedded in HTML, whereas service-defined functions can be injected and applied wherever needed.

"But I won't need to reuse the function!" - Think again! While immediate reuse may not seem necessary, future scenarios may call for integrating that function elsewhere. Start off correctly by shifting most logic to services. This way, when the need arises, you can seamlessly transfer the function to new contexts without adapting it to fit existing scope structures.

Remember, services lack knowledge of scope, so opting for the initial version simplifies implementation. And resist the urge to pass an entire scope to a service; that road only leads to trouble :-)

Hence, in my opinion, the preferred setup would be:

app.service('ToDoService', [function(){
    this.addToDo = function(params1, ...){
        alert(params1);
    }
}]);

And within the controller:

$scope.addToDo = ToDoService.addToDo;

---

Note the mention of a "general rule." Some situations may warrant defining functions within the controller itself rather than resorting to a service. For instance, when a function pertains solely to scope-specific tasks, such as toggling controller states. However, based on the context presented here, that doesn't seem to be the case.

The philosophy behind Angular, as detailed in the video Zen of Angular, emphasizes these guidelines:

ng-model and ng-click, there may be ambiguity in their order of execution. To address this issue, utilizing ng-change ensures a clear sequence: it triggers only after the value has been changed.

    

Custom behavior methods like ng-click and ng-submit give us the ability to pass parameters to the methods being called. This is crucial when we need to pass data that may not be easily accessible within the controller handler. For example,

angular.module('TestApp')
.controller('TestAppController', ['$scope', function($scope) {
    $scope.handler = function(idx) {
        alert('clicked ' + idx.toString());
    };
}]);

<ul>
    <li ng-repeat="item in items">
        <button ng-click="handler($index)">{ item }</button>
        <!-- $index is an iterator automatically available with ngRepeat -->
    </li>
</ul>

In your second example, since allChecked is in the same scope as the controller defining markAll(), there is no need to pass anything. We would just be duplicating data.

The method can simply be refactored to utilize the existing scope variables.

$scope.markAll = function () {
    todos.forEach(function (todo) {
        todo.completed = $scope.allChecked;
    });
};

Therefore, while we have the option to use parameters in these methods, they are only necessary under certain circumstances.

It appears that the issue at hand is simply a matter of inconsistent coding practices. After contemplating this query in the past, I have reached a conclusion...

Guideline: Avoid passing $scope variables into $scope functions.

The controller code should clearly showcase the function of the component, without embedding any business logic in the view itself. The view should primarily consist of bindings (such as ng-model, ng-click, etc.). If moving certain elements to the controller enhances clarity in the view, then it is advisable to do so.

Exception: Conditional ng-class statements are acceptable (e.g.,

ng-class='{active:$index==item.idx'

) - since incorporating class conditionals in the controller can be cumbersome and convolute the logical flow between the controller and the view. Visual properties should remain within the view.

Exception: An exception is made when working with items in an ng-repeat directive. For instance:

<ul ng-repeat="item in items">
    <li><a ng-click="action(item)"><h1>{{item.heading}}</h1></a></li>
</ul>

I adhere to these guidelines while developing controllers and views, and I find them to be effective. Hopefully, this insight proves helpful.

Maybe it's to showcase your capability? As long as they are the same controller, there is no practical distinction between the two. Keep in mind that in certain scenarios, child scopes may be created, resulting in a different scope from the controller.