Page 1 of 1

Discussion: Some more Warnings

Posted: Sat Jan 19, 2013 10:59 pm
by Franky
Hi there,
It's been some time now since aside compilererrors compilerwarnings where implemented in PureBasic.
But in my opinion this feature could be much more powerful if it would be used more often in the compiling/debugging-Process.
Some more warnings would lead to cleaner, better understandable and less buggy codes from the PB-Users. :)
I think most people would like to enable/disable such warning features, so optionality would be good.


Here's a list of what I would like to have added as warnings, feel free to discuss or add your own list.
  • Warnings for conditions with missing ProcedureReturn to avoid creating bugs without recognizing:
    Example

    Code: Select all

    
    Procedure MyWork(Wert.l)
      Protected *lbuffer
      If Wert<$7FFF And Wert>0
        *lbuffer=AllocateMemory(10000)
        If *lbuffer
          For a=1 To 10000
            PokeW(*lbuffer,Wert)
            *lbuffer+1
          Next
        Else
          ProcedureReturn 1
        EndIf
      ElseIf Wert>-10
        ProcedureReturn -1
      EndIf
    EndProcedure
    
    Here we have 2 conditions in which there is no defined ProcedureReturn (which is equal to ProcedureReturn 0).
    Of course in some cases, 0 would be correct or at least both could have the same allowed return that could be written in the last line.
    But sometimes you have to check inside each condition for the right return. The compiler could help checking this.
  • It would be nice to be able to turn all Errors created by Enable Explicit into Warnings.
    1.)Sometimes you only need a quickcheck what's todo on a code snippet you want to import
  • Warnings for partly incompatibility of types.
    Example:

    Code: Select all

    Procedure.l MyValue(lmyval.l,lmax.l)
      If lmyval>lmax
        ProcedureReturn lmax
      Else
        ProcedureReturn lmyval
      EndIf
    EndProcedure
    
    Global wValue.w
    Global a.l
    
    For a=0 To 100000
      wValue=MyValue(a,Random(100000))
      If a%100=0
        Debug wValue
      EndIf
    Next
    
  • Warnings for defined but unused variables, that helps to have a cleaner code
    I mentioned it here because I think it's useful, even though I already found this thread
    where it's also discussed.
    It's here just to have my list complete for me. :mrgreen:
  • A CompilerWarning "Message" or DebuggerWarning "Message" Function
    There are multiple reasons why it should not be a CompilerWarning or Debug:
    0.)It should not stop the debugging or compiling process but return some message like "WARNING: Include xyz.pbi Line 20 Procedure XY(If possible): "Message".
    1.)It would be good to have all warnings in one Window (for example the list in the bottom of the PB-IDE-Window) and not in the DebugWindow which in my opinion should be used to Debug variables for the snippet you're currently working on. A good thing would be that you could compile multiple times when having a bug in some of your code and when having that fixed, you could take a look at the Warnings-List
    2.)Any programmer could add such warnings to define for example a variables Range for his includes functions.
    This could help other programmers to avoid bugs by using the wrong variables or missing a value check before calling a Procedure.
  • TypeCheck for Procedure Parameters
    Especially when working with structures, a typing error is not recognized and can lead to very ugly bugs. :mrgreen:
    PureBasic knows (at least with EnableExplicit) every variabls type. So, this check should be possible.
  • Change some Errors to Warnings
    Example:

    Code: Select all

    If OpenWindow(1,100,100,200,200,"Hi there")
      EditorGadget(1,0,0,200,180)
      ButtonGadget(2,0,180,100,20,"Wrong field")
      ButtonGadget(3,100,180,100,20,"Right field")
      Repeat
        
        event=WaitWindowEvent()
        
        If event=#PB_Event_Gadget
          Select EventGadget()
            Case 2
              SetGadgetText(0,"That will never be visible")
            Case 3
              SetGadgetText(1,"That's shown")
          EndSelect
        EndIf
      Until  event=#PB_Event_CloseWindow
    EndIf
    
    That's not a real Error (this is why users are able to click "Play" again) but a warning.
    If wanted, the User should be able to switch that to Warning.

So, what do you think about that?

Best Regards

Franky

Re: Discussion: Some more Warnings

Posted: Sun Jan 20, 2013 5:00 am
by BorisTheOld
I want a compiler to tell me what mistakes I actually made, not what mistakes it thinks I made. How can a compiler possibly know why I write my code the way I do. Perhaps I want unused variables, mismatched data types, or "missing" ProcedureReturn statements.

Although warnings are useful, too many warnings are not. And I think all your ideas will create many, many warnings for code that is perfectly valid. It certainly would with mine.

The way to write good software is to do it right the first time, and not rely on the compiler to clean up your sloppy code.

Re: Discussion: Some more Warnings

Posted: Sun Jan 20, 2013 5:12 am
by MachineCode
Franky wrote:Here we have 2 conditions in which there is no defined ProcedureReturn
Good. ProcedureReturn is not mandatory. The compiler, as Freak once said, is not a mind-reader and simply cannot know if you actually wanted a ProcedureReturn there. Therefore, warnings shouldn't be given for it, otherwise every procedure would get such a warning.

Re: Discussion: Some more Warnings

Posted: Sun Jan 20, 2013 2:28 pm
by luis
Warnings (wisely selected) are very useful in my opinion when they are paired with a robust way to handle them.

1) The ability to disable all warnings globally.
2) The ability to disable a specific warning through a compiler directive for a segment of code.
3) The ability to globally disable a specific warning permanently.

Without all this, I probably prefer to not have them in the way.

The warning I miss more then anyone else, and you mentioned it, is the one about variables defined but not used.
After this one has been implemented, we can talk about others as well :)

Re: Discussion: Some more Warnings

Posted: Sun Jan 20, 2013 5:53 pm
by Franky
luis wrote:Warnings (wisely selected) are very useful in my opinion when they are paired with a robust way to handle them.

1) The ability to disable all warnings globally.
2) The ability to disable a specific warning through a compiler directive for a segment of code.
3) The ability to globally disable a specific warning permanently.

Without all this, I probably prefer to not have them in the way.
Definitly, me too. Being able to disable these warnings is important.
And especially, a warning should not break the compiling- or debugging-Process anyhow.

Re: Discussion: Some more Warnings

Posted: Sun Jan 20, 2013 6:08 pm
by skywalk
+1 luis
http://www.purebasic.fr/english/viewtop ... =+debugger
It would be great to have an unused variable dump.

Re: Discussion: Some more Warnings

Posted: Sun Jan 20, 2013 7:51 pm
by langinagel
I too would appreciate some kind of a static analysis on the code.
Unused variables will play the greatest role since PureBasic initialises variables, as C does not.

Some more criteria for static analysis might be the MISRA-Code rules or others. Maybe some checking similar to Lint (PCLint, or others Splint (free!)) might be used.
Examples may be:
Improper variable comparison (float = value)
improper casting of variables (O.w = t.f * d.l )
[i don't have all the stuff in mind or on a sheet next to me...google for yourself.]

The static analysis function might be additional, not included in the compiler-run.

If purebasic would have some static code checking facilities it would maybe play in the league of C, ADA and Pascal for desktop applications. And sure: it would be a good argument to rise the price ;-).

Greetings
Thorsten

Re: Discussion: Some more Warnings

Posted: Mon Jan 21, 2013 4:52 am
by MachineCode
skywalk wrote:It would be great to have an unused variable dump.
And an uncalled procedures dump, so we can remove unused procedures and reduce our exe sizes.

Re: Discussion: Some more Warnings

Posted: Mon Jan 21, 2013 5:06 am
by Shield
Side note: That's what PB does to some extent, if the procedures aren't referencing each other.
I'm not sure if anything changed regarding this, but if not a full and proper scan would be great. :)

Anyway, +1 on warnings.

Re: Discussion: Some more Warnings

Posted: Mon Jan 21, 2013 5:08 am
by MachineCode
Shield wrote:That's what PB does to some extent
It doesn't do a good job, though. An exe made with the uncalled procedures, and then with those procedures removed, will be of vastly different sizes.

Re: Discussion: Some more Warnings

Posted: Mon Jan 21, 2013 1:14 pm
by luis
It doesn't do anything actually, intentionally I mean. The outcome is entirely based on the fact every procedure is wrapped inside a ASM macro. A nice trick to get 'something' removed.
The macro not invoked at the end are not expanded.
For an example see -> http://www.purebasic.fr/english/viewtop ... 03#p300303

BTW: I'm waiting for this to be hopefully implemented -> http://www.purebasic.fr/english/viewtop ... =3&t=48235 to make a tool to process and discard unused procedures :wink:

Re: Discussion: Some more Warnings

Posted: Mon Jan 21, 2013 2:21 pm
by Little John
If and when I'll have more free time, then I'll extend my preprocessor LPP so that it can remove unused variables and procedures. Of course, I'd also prefer that the PB compiler would do that itself. :-)

Regards, Little John

Re: Discussion: Some more Warnings

Posted: Mon Jan 21, 2013 2:53 pm
by luis
Little John wrote:If and when I'll have more free time, then I'll extend my preprocessor LPP so that it can remove unused variables and procedures.
I looked into it, but I found it to be practically impossible to do it reliably right now. Just think about includes. The include statement can be not "plain", but generated with a macro. The same thing for procedures. A procedure can be split in multiple unrecognizable pieces and build together again through a macro. You can have conditional compilation again mixed with macros.

Unless you rewrite the PB parser from scratch and keep it constantly updated with each and every new version you will have a mediocre result at best, not working in many real life cases. That's why there is no code of this kind really working in the forum.

The right person to do that work is Fred, that's why I hope he will implement that feature request.
Little John wrote:Of course, I'd also prefer that the PB compiler would do that itself. :-)
That would be the best thing, because even with the preprocessing done for us, there would be some minor things difficult to track.
For example enabled plugin dependencies for a procedure now removed, and others things.
But I would be happy enough with the preprocessed file !