CF function CF_CFDP_IsSender(transaction_t *ti) is odd one out because it uses ti about cf

[astrogeco]

CF/fsw/src/cf_cfdp.c

Lines 142 to 161 in 96cdf30

	static inline CF_CFDP_Class_t CF_CFDP_GetClass(const CF_Transaction_t *ti)
	{
	CF_Assert(ti->flags.com.q_index != CF_QueueIdx_FREE);
	return !!((ti->state == CF_TxnState_S2) || (ti->state == CF_TxnState_R2));
	}
	/*----------------------------------------------------------------
	*
	* Function: CF_CFDP_IsSender
	*
	* Internal helper routine only, not part of API.
	*
	*-----------------------------------------------------------------*/
	static inline int CF_CFDP_IsSender(CF_Transaction_t *ti)
	{
	CF_Assert(ti->flags.com.q_index != CF_QueueIdx_FREE);
	/* the state could actually be CF_TxnState_IDLE, which is still not a sender. This would
	* be an unused transaction in the RX (CF_CFDP_ReceiveMessage) path. */
	return !!((ti->state == CF_TxnState_S1) || (ti->state == CF_TxnState_S2));
	}

[skliper]

While I do appreciate not wasting characters... neither ti or t are all that descriptive/helpful in terms of variable names. Maybe transaction or txn or similar? I'd consider either of these options more "readable".

[thnkslprpt]

While I do appreciate not wasting characters... neither ti or t are all that descriptive/helpful in terms of variable names. Maybe transaction or txn or similar? I'd consider either of these options more "readable".

I would tend to agree with you Jake.
However, there are several hundred uses of all 3 options (t, txn & transaction) in the code base. So for now, it might be best to just correct this particular instance.
For CF_Transaction_t objects specifically, they practically all use ‘t’, so we can align these 2 aberrations to the majority, like Alan Gibson suggested.
Perhaps future work could focus on improving the argument names in general, to make them more readable.