Return to Answer

I would use:

anEvent.WhatId?.getSObjectType() == Opportunity.SObjectType 

so you avoid the describe call that is relatively expensive (taking a few milliseconds). This is also a cleaner form of the type check: you are comparing two SObjectType values. The ?. avoids a null pointer exception if WhatId is ever null.

A benefit of Apex compared to most programming languages is that the names of the database tables (SObjects) and columns (fields) are available as compile-time checked enum-like SObjectType and SObjectField references. This is for both the platform's standard SObjects and any custom SObjects your create. So stick with those rather than using strings.

I would use:

anEvent.WhatId?.getSObjectType() == Opportunity.SObjectType 

so you avoid the describe call that is relatively expensive (taking a few milliseconds). This is also a cleaner form of the type check: you are comparing two SObjectType values. The ?. avoids a null pointer exception if WhatId is ever null.

A benefit of Apex compared to most programming languages is that the names of the database tables (SObjects) and columns (fields) are available as compile-time checked enum-like SObjectType and SObjectField references. This is for both the platform's standard SObjects and any custom SObjects your create. So stick with those rather than using strings.

I would use:

anEvent.WhatId?.getSObjectType() == Opportunity.SObjectType 

so you avoid the describe call taht is relatively expensive (taking a few milliseconds). This is also a cleaner form of the type check: you are comparing two SObjectType values. The ?. avoids a null pointer exception if WhatId is ever null.

A benefit of Apex compared to most programming languages is that the names of the database tables (SObjects) and columns (fields) are available as compile-time checked enum-like SObjectType and SObjectField references. So stick with those rather than using strings.

I would use:

anEvent.WhatId?.getSObjectType() == Opportunity.SObjectType 

so you avoid the describe call that is relatively expensive (taking a few milliseconds). This is also a cleaner form of the type check: you are comparing two SObjectType values. The ?. avoids a null pointer exception if WhatId is ever null.

A benefit of Apex compared to most programming languages is that the names of the database tables (SObjects) and columns (fields) are available as compile-time checked enum-like SObjectType and SObjectField references. This is for both the platform's standard SObjects and any custom SObjects your create. So stick with those rather than using strings.

I would use:

anEvent.WhatId?.getSObjectType() == Opportunity.SObjectType 

so you avoid the describe call that can be expensive (taking a few milliseconds). This is also a cleaner form of the type check: you are comparing two SObjectType values. The ?. avoids a null pointer exception if WhatId is ever null.

A benefit of Apex compared to most programming languages is that the names of the database tables (SObjects) and columns (fields) are available as compile-time checked enum-like SObjectType and SObjectField references. So stick with those rather than using strings.

I would use:

anEvent.WhatId?.getSObjectType() == Opportunity.SObjectType 

so you avoid the describe call taht is relatively expensive (taking a few milliseconds). This is also a cleaner form of the type check: you are comparing two SObjectType values. The ?. avoids a null pointer exception if WhatId is ever null.

A benefit of Apex compared to most programming languages is that the names of the database tables (SObjects) and columns (fields) are available as compile-time checked enum-like SObjectType and SObjectField references. So stick with those rather than using strings.