Return to Answer

Certainly the while loop is linear in size of article string s. But you're restarting that linear .index() search from the beginning each time, leading to nested loop \$O(N × M)\$ behavior if content c appears \$M\$ times within the article. Given \$M << N\$ an efficient algorithm should see article size dominate the cost, with negligible contribution from the censoring operations.

Usually we give 0 and 1 a pass when it comes to calling out magic numbers. But here isn't needed, there's no need for such cryptic indexes. Prefer a tuple unpack:

Certainly the while loop is linear in size of article string s. But you're restarting that linear .index() search from the beginning each time, leading to nested loop \$O(N × M)\$ behavior if the censored c appears \$M\$ times within the article. Given \$M << N\$ an efficient algorithm should see article size dominate the cost, with negligible contribution from the censoring operations.

Usually we give 0 and 1 a pass when it comes to calling out magic numbers. But here it obscures Author's Intent, there's no need for such cryptic indexes. Prefer a tuple unpack:

Certainly the while loop is linear in size of article string s. But you're restarting that linear .index() search from the beginning each time, leading to nested loop \$O(N × M)\$ behavior if the censored c appears \$M\$ times within the article. Given \$M << N\$ an efficient algorithm should see article size dominate the cost, with negligible contribution from the censoring operations.

Usually we give 0 and 1 a pass when it comes to calling out magic numbers. But here it's just silly, there's no need for such cryptic indexes. Prefer a tuple unpack:

Certainly the while loop is linear in size of article string s. But you're restarting that linear .index() search from the beginning each time, leading to nested loop \$O(N × M)\$ behavior if content c appears \$M\$ times within the article. Given \$M << N\$ an efficient algorithm should see article size dominate the cost, with negligible contribution from the censoring operations.

Usually we give 0 and 1 a pass when it comes to calling out magic numbers. But here isn't needed, there's no need for such cryptic indexes. Prefer a tuple unpack:

Certainly the while loop is linear in size of article string s. But you're restarting that linear .index() search from the beginning each time, leading to nested loop \$O(N × M)\$ behavior if content c appears \$M\$ times within the article. Given \$M << N\$ an efficient algorithm should see article size dominate the cost, with negligible contribution from the censoring operations.

Usually we give 0 and 1 a pass when it comes to calling out magic numbers. But here isn't needed, there's no need for such cryptic indexes. Prefer a tuple unpack:

Certainly the while loop is linear in size of article string s. But you're restarting that linear .index() search from the beginning each time, leading to nested loop \$O(N × M)\$ behavior if the censored c appears \$M\$ times within the article. Given \$M << N\$ an efficient algorithm should see article size dominate the cost, with negligible contribution from the censoring operations.

Usually we give 0 and 1 a pass when it comes to calling out magic numbers. But here it's just silly, there's no need for such cryptic indexes. Prefer a tuple unpack: