I wonder if we can/should also lint that you don't otherwise initialize variables in State objects, e.g.

class FooState extends State<Foo> {
  // Should be initializing this in initState rather than here
  final MySpecialControllerThatDoesNotNeedThis _controller = MySpecialControllerThatDoesNotNeedThis(bar: 3);

  ...
}

That seems overly limiting. It's totally fine (and common) to initialize a TextEditingController like that, for example.

Maybe if it's late final but if it's final you might be initializing an object you'll never use right?

What does the word "logic" mean in this context? The proposed implementation flags constructors whose body is not empty, implying that no code should be executed when an instance is created, but that appears to conflict with the claim that it's acceptable to initialize a TextEditingController (though if it's only late final fields that can have initializers, then that would be consistent with not executing code when the instance is created).

I don't think there are any actual conflicts, but I agree that we could be a little bit more specific with what we mean by "logic executed at instance creation". Maybe we should mention that initializations, such as creating instances of a TextEditingController (which is ultimately logic being executed when an instance of a State is created), should be performed in initState or defined in conjunction with the declaration of its respective member, while all other code should be executed in initState.

BAD:

class FooState extends State<Foo> with SingleTickerProviderStateMixin {
  FooState() {
    // It's best if you don't do anything here
    _animationController = AnimationController(vsync: this);
    _textEditingController = TextEditingController();
    _myMethod();
  }

  late final AnimationController _animationController;
  late final TextEditingController _textEditingController;
  // ...
}

Good:

class FooState extends State<Foo> with SingleTickerProviderStateMixin {
  // Declare members here
  late final AnimationController _animationController;
  late final TextEditingController _textEditingController;

  @override
  void initState() {
    super.initState();
    // Initialize members and execute all other code here
    _animationController = AnimationController(vsync: this);
    _textEditingController = TextEditingController();
    _myMethod();
  }
  // ...
}

Good:

class FooState extends State<Foo> with SingleTickerProviderStateMixin {
  // Declare and initialize members here
  late final AnimationController _animationController = AnimationController(vsync: this);
  final TextEditingController _textEditingController = TextEditingController();

  @override
  void initState() {
    super.initState();
    // Execute all other code here
    _myMethod();
  }
  // ...
}

Bottom line is that logic executed at creation of a State instance is fine. But it shouldn't happen in the constructor body because that often doesn't go well with the rest of the State lifecycle.

Is the proposal here that a State constructor should not even have a body? Or is it a set of statements that should be banned, like assignments, method calls, ...

Without additional information we're not able to resolve this issue, so it will be closed at this time. You're still free to add more info and respond to any questions above, though. We'll reopen the case if you do. Thanks for your contribution!